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ABSTEACT 



In this thesis we describe the design and implementation 
of two prototype interpreters fcr Omega, an object-oriented, 
production- rule programming language. The first implementa- 
tion is a throw-away prototype written in LISP; the second 
implementation is a more complete version written in C. The 
Omega language features two major components: a set of 
production rules executed through pattern-directed invoca- 
tion, and a relational database of values and objects. We 
develop a simple system of rale evaluation which relies on 
hashed indexing for rule selection and a list implementation 
of relations. The system’s performance is evaluated in 
comparison with LISP and Prolog interpreters. We conclude 
with a discussion of our experience in developing example 
applications, and recommend extensions to the language based 
on this experience. 
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I. INTEODDCTION 



A. BACKGROUND 

Two major issues in programming language design can be 
characterized as abstraction and architecture. In this 
context/ abstraction refers to the ability of the language 
to capture the ideas of the programmer. It is a measure of 
expressiveness or semantic power. Architecture refers to 
those language characteristics, both organizational and 
syntactic, that affect practical usage. This includes ease 
of use for the programmer as well as the potential for effi- 
cient implementation. Thus an important goal for a program- 
ming language is to combine a powerful abstraction ability 
with an effective language architecture. 

Conventional languages have suffered in both of these 
areas. These languages focus on the use of assignment 
statements for computation, and execution consists of the 
sequential flow of program control between assignment state- 
ments. John Backus described these "von Neumann" languages 
as excessively complex and weak, whose word-a t-a-time 
conceptual basis has created an "intellectual bottleneck" 
[Ref. 1: p, 615]. These languages are oriented more towards 
the word-at-a- time stored program computer than towards the 
problem domains they attempt tc satisfy. Thus they have 
poor abstraction ability. While simple, elegant imperative 
languages such as Pascal have enjoyed popularity, the need 
for increased power has resulted in complex languages such 
as Ada. Such languages have attained semantic power at the 
expense of architectural effectiveness. 

Several alternatives to the von Neumann languages have 
been developed- Of interest in this thesis are applicative 



languages, object-oriented languages, and rule-based infer- 
ence languages. 

B. APPLICATIVE LANGUAGES 

Applicative languages use the application of a function 
to its arguments as the focus for computation. These 
languages are typified by pure LISP [Ref. 2], and by later 
functional languages such as FP [Ref. 1] and KRC [Ref. 3], 

The strengths of the applicative languages are exempli- 
fied by arithmetic expressions. These strengths include 
clear interfaces between computational units, relative inde- 
pendence of evaluation order, and a semantic regularity that 
lends itself to simple verification and proof technigiies. 

Functionals, functions which receive functions as argu- 
ments and return functions as results, provide a mechanism 
for the combination of simple, primitive computational units 
into collections of arbitrary power and complexity. 

The applicative languages achieve their predictability 
largely from the prohibition of side-effects during computa- 
tion. This characteristic limits the problem domains to 
which applicative solutions can be readily applied. Like 
the arithmetic expression, applicative languages cannot 
readily describe the notion of state. There is no explicit 
notion of time in an arithmetic expression, and applicative 
languages are correspondingly vieak in maintaining temporal 
relationships. This characteristic limits the utility of 
applicative languages in inherently state-oriented applica- 
tions. Such applications include operating system activi- 
ties, data base management, and discrete simulation. 

C. OBJECT-ORIENTED LANGUAGES 

The object-oriented languages have developed from simu- 
lation languages such as Simula [Ref. 4], and are typified 
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by Smalltalk [Ref. 5]. Smalltalk partitions the program- 
mer's model into collections of objects called classes. 
Objects have a state associated with them, and the methods 
(procedural information) of the class determine an object's 
computational behavior. Both data and procedural informa- 
tion are organized around the object. 

The object-oriented approach allows certain important 
capabilities. Foremost, the concept of state is fully 
ingrained in the language. The simulation approach facili- 
tates the modeling cf real-world activities, with concur- 
rency readily handled through the mechanism of communicat ing 
ob j ects . 

Associated with the class mechanism in Smalltalk is the 
concept of inheritance. When a new object is created, it 
obtains certain default state and behavioral characteristics 
from its class. In the functional languages, combinatorial 
power is obtained through subordinate function application 
and the use of functionals. In the object-oriented 
approach, combinatorial power is obtained through composi- 
tion of new objects from existing ones, and through 
inheritance. 

D. INFERENCE SYSTEMS AND LOGIC PROGRAMMING 

Inference systems have developed through artificial 
intelligence efforts at cognitive modeling, knowledge repre- 
sentation, and theorem proving. Based on the early produc- 
tion system of Post [Ref. 6], these systems use rules, 

similar to logical implication, that provide the computa- 
tional framework for a program. Rule-based organization has 
been described by Newell [Ref. 7], and an early language 
based on the concept was Hewitt's PLANNEE [Ref. 8]. 
Numerous rule-based systems have since been developed, with 
notable examples being theorem provers such as AH [Bef. 9], 
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and expert systems such as MYCIN [Ref. 10], 

[Ref. 11], and PROSPECTOR [Ref. 12]. 

Prolog is a general-purpose language which uses rule- 
based theorem proving as the computational metaphor 
[Ref. 13]. Distinct from the applicative languages, Prolog 
uses pattern-matching instead of the procedure call to 
determine the applicability cf rules and the resulting 
computations. 

Z. A COHBINED APPROACH 

The preceding discussion highlights the following 
features offered by these languages; 

• Function application provides a powerful, regular mecha- 
nism for stateless computation. 

• An object-oriented approach provides an effective organ- 

ization for data and procedures which is useful in 
representing temporal relationships and real-world 

objects. 

• Rule-based pattern-matching systems have provided an 

alternative way for expressing complex knowledge 

\ representation. 

The Omega language [Bef. 14] represents an approach that 
combines these features into a single language framework. 

F. AN IMPLEMENTATION STUDY 

The emphasis of this thesis is on the implementation of 
an interpreter for the Omega language. As an implementation 
study, the focus is on language architecture — those charac- 
teristics of the language that were conducive or that 
presented obstacles to efficient implementation. Of partic- 
ular interest in this effort are the charact er istics of 



15 



data representation, 



interpreter organization, data representation, and control 
strategies used in the implementation, and how these charac- 
teristics impact on the performance of the system. 

This work is a prototyping effort. Because of the 
experimental nature of the language, various extensions and 
modifications were required on preliminary designs. To 
support this experimentation, two prototypes for the inter- 
preter were written. The first was a throw-away prototype 
written in Franz LISF. The second was a more complete, 
incremental development written in C. 



G. A SUBJECTIVE EVALUATION 

As a secondary emphasis, some attention is given in this 
work to the evaluation of Cmega as a general-purpose 
programming language. While these observations are largely 
subjective, they provide some insight into the implementa- 
tion problems associated with these early prototypes. 
Having prototype interpreters up and running has also 
provided an opportunity for experimentation with Omega 
programming that may prove useful in the early evaluation of 
features in the language. 
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II. AN INF0R3AL DESCRIPIION OF THE LANGUAGE 



A. GENERAL 

This chapter provides a descriptive summary of the 
features of the Omega language. The descriptions are mainly 
by example, and serve to provide a feel for the language 
constructs, not detail. 

The material in this chapter is based on the work of 
MacLennan. The philosophy, informal and formal semantics, 
and original syntax of the language are introduced in 
[Ref. 14]. Some syntactic and semantic differences exist 
between the original description of the language given in 
[Ref. 14] and the prototype implementations. Later chapters 
will deal with the rationale for these deviations. The 
implementation syntax is used in this chapter to maintain 
consistency with with the remainder of this thesis. A 
description of the implementation syntax is contained in 
Appendix A. 

B. OBJECTS AND VALUES 

The entities of the system are divided into values and 
objects. The values of the system include numerics (inte- 
gers and reals) , character strings, and lists. Lists are 
denoted by square brackets, such as: 

["a", "b", [1, 2]]. 

Objects are referenced by name,' and are subject to the 
following properties; 

• Objects are unique. 

• Objects may be shared. 
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• objects are subject to change over time. 

• Objects may be created and destroyed. 

The distinction between objects and values is discussed in 
[Eef. 15]. Subsequent examples should help to illustrate 
the rcle of objects in Omega. 

C. A EELATIONAL MODEL 

The components of the language are organized according 
to a relational model. The model is consistent with rela- 
tional terminology introduced by Godd [Ref. 16]. 

Consider an object that represents a queued process 
waiting for an operating system resource. For reference 
purposes/ the object must be named, so call it J. 
Associated with the object are a priority, P, and a tape 
drive allocation requirement, T. The priority and resource 
requirements are values that must be associated with the 
job. These associations may be described by a Priority 
relation and a TapeDrive relation. This could be expressed 
as Priority(J^ P) , TapeDrives ( J , T) . In these expressions, 
the pairs <J, P> and <J, T> are called tuples. 

A tuple is an ordered collection of objects and values. 
Note that, unlike relational database models, named attri- 
butes are not used to describe a tuple. Instead, the 
members of a tuple are described by relative position (order 
is important), by value, and by pattern-matching. 

A relation is a set of tuples. Relations are described 
by name, and through pattern-matching. As a set, the tuples 
of a relation are (1) unique and (2) unordered. 

Objects serve as representative place holders in rela- 
tions. The state of an object is determined by the rela- 
tions in which it participates, and by the attributes 
associated with the object in these relations. 
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Relations themselves are objects, although they are 
distinguished by having an intrinsic value: the collection 
of tuples instantiating the relation. As objects, relations 
may be members of tuples and participate in other relations. 

D. PATTERN-DIRECTED PRODDCTION ROLES 

The relations organize the primitives of the system. 
Thus, at a given time, the state of the system is character- 
ized by its relations and the entities bound through these 
relations. To complete the model, a mechanism must be used 
to describe state transitions. Pattern-directed production 
rules are used for this purpose. 

A rule is a pair <a , c>, where a is termed an antecedent 
and c a consequent. An antecedent consists of Boolean 
conditions that pertain to the state of the system. The 
consequent consists of actions that will be executed if the 
conditions of the antecedent are true. Rules are written: 

if <antecedent> -> <consequent>. 

A condition may be one of several constructs. The most 
fundamental is the inquiry. An inquiry is a pattern-matched 
test described by the rule that is performed against the 
relations of the system. As an example, consider the job 
queue again. A rule may be desired that checks for jobs 
requesting 4 tape drives. This could be expressed as: 

if TapeDrives ( j , 4) -> . . . 

where the consequent of the above rule is not shown. The 
expression TapeDrives (j, 4) is an inquiry, and may be read 
as "if there is a tuple <entity, 4> in the TapeDrives rela- 
tion, then return true and bind the entity to the variable 
j." The symbol j in this example is an unbound logical 
variable, which is considered a wild card in an attempt to 
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match the inquiry against the tuples of the relation. Once 
a logical variable has become bcund through an inquiry, this 
binding will remain in effect for that particular rule. 

The following, more complex, inquiry relies on variable 
binding: 

if TapaDrives ( j , n) , Priority(g, p) -> . . . 

The comma is considered as a logical "and" between the two 
inquiries. Thus, the antecedent of this rule will be evalu- 
ated as true if tuples exist in the TapeDrives and Priority 
relations such that the first member of each tuple is the 
same. This corresponds to the equality join of relational 
database systems. 

It is important to note that inquiries are existentially 
quantified. An inquiry is evaluated as "if there exists a 
tuple <x1, xn> in relation R, return true." 

It is also important to note that the logical variable 
binding done during pattern-matching is in effect only for 
the duration of the rule. The scope of a logical variable, 
then, is the rule where the variable occurs. 

Other variables may have more permanent bindings, and 
behave like constants. There is no syntactic distinction 
between free and bound variables. To avoid confusion in 
examples, free logical variables will always begin with a 
lower case letter, bound variables and constants will begin 
in upper case. 

Another type of antecedent condition is a test for the 
absence of a tuple. This condition has the form 

if -^TapeDrives { j, 4) -> . . . 

which is read "if it is not the case that a tuple <j, 4> 
exists in the TapeDrives relation." If the tuple pattern is 
not a member of the relation, the expression is evaluated as 
true . 
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The absence of a tuple from a relation might or might 
not be interpreted as the negation of its presence. If one 
uses a "closed world" assumption, then absence is the same 
as negation. The logical interpretation of an absence test 
is dependent on the programmer's intent and assumptions. 

Free variables are not bound in an absence test. 
Consider again the rule: 

if -iTapeDrives ( j, 4) -> . . . 

For the antecedent to be true, there is no tuple <j, 4> in 

the TapeDrives relation. Therefore, the free variable j 
will remain unbound. 

The inquiry and absence conditions form the basis for 
the evaluation of the current state of the system. An addi- 
tional mechanism is provided for the evaluation of state 
information. This mechanism is termed a constraint, and can 
be any Boolean expression. 

Consider the case where one is interested in determining 
if a job requires more than 5 tape drives. This could be 
expressed as : 

if TapeDrives { j , n),n>5->. . . 

where the expression n > 5 is a constraint. The join 

example shown previously could he rewritten as 

if TapeDrives( j 1, n) , Priority (j2, p) , j1=j2 -> . . . 

The consequent portions of rules alter the state of the 
system. The actions of the consequent typically update 
relations in some way. The fundamental actions are asser- 
tions and deletions. 

An assertion adds a tuple to a relation. Consider the 
rule: 



if Request { resource, job). Avail (resource) -> 
Allocate (resource, job). 



If the contents of the Reguest and Avail relations match the 
inquiry patterns, the rule will "fire", and add the tuple 
<resource, job> to the Allocate relation. 

In the previous example, the free variables resource and 
job were bound in the antecedent portion of the rule. These 
bindings were maintained through the consequent portion of 
the rule and determined the instantiation of objects added 
to the Allocate relation. Free variables, therefore, must 
be bound through pattern-matching before their use in the 
consequent of a rule. 

The allocation example raises some problems. The rule 
successfully allocates a resource to a job by the assertion 
to the Allocate relation. This assertion, however, does not 
alter the conditions Request and Avail that initiated the 
rule's firing. Thus, this rule may conceptually "fire 
forever" unless some action is taken to disable one or more 
of its conditions. 

The deletion is used for this purpose. The allocation 
rule may be written as: 

if Request (resource , job). Avail (resource) -> 

-•Request (resource, job), 

-•Avail (resource) , 

Allocate (resource , job). 

The deletions -^Reguest (resource , job) and ->Avail (resource) 
remove the indicated tuples from their relations. 

The preceding actions — determine a pattern-match cf a 
tuple within a relation, then remove the tuple — is a typical 
sequence. An abbreviated syntax for this sequence is the 
cancel operation. Using cancel operations, the preceding 
rule may be written: 

if ^(‘Reques t (resource, job) , *Avail (resource) -> 

Allocate (resource, job). 
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The cancel operation returns true if the indicated pattern 
is matched against a tuple in a relation. If the antecedent 
of the rule succeeds (all conditions are true) , then the 
tuples matched during cancel operations are deleted from 
their relations. 

Eules may be coupled through alternation. In the 
preceding rule, an alternate action may be desired if the 
requested resource is not available. This is expressed as: 

if *Eeguest (resource, job), *Avail (resource) -> 

Allocate (resource, job) 
else if *Reguest (resource, job) -> 

Block ed (resource, job). 

The antecedent of the alternate rule will be evaluated if 
the primary rule fails. In this example, the effect will be 
to place the job in a blocked state. 

E. THE APPLICATIVE COMPONENT 

Function application is used to support the state tran- 
sitions described above. In those cases where a tuple must 
be specified, an applicative expression may be used to 
compute the value of a member. Consider the following rule: 

if *TapeDrives ( j, n) , n + 1 <= 10 -> 

TapeDri ves (j , 2 * n) . 

This rule uses infix arithmetic operators to compute values 
in a constraint and during an assertion. Such operators are 
permissible in constraint expressions and in the consequent 
portions of the rule, with the restriction that variables 
participating in such expressions must be bound. In the 
preceding example, the variable n was bound in the 
TapeDrives inquiry. 
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Named functions may also be used within expressions in 
the same way as the infix operators. This is shown in the 
following rule: 

if *Av ailTapeDrives (LI ) , * lapeQueue (L2) , 

(11 1= Nil) S (12 -= Nil) -> 

AvailTapeDrives (Rest [ 11 ]) , 

TapeQueue (Kest[ 12 ]) , 

Allocate (First[ LI ], First[12]). 

In this example, available tape drives and jobs queued for 
tape drives are represented as lists. The functions 
First£x] and Rest[x] return the head and tail pointers of 
their argument. 

Functions are declared as fellows: 

fn fact[x] : if X <= 1 -> 1 

else X * fact[x-1 j. 

This example illustrates that function bodies are similar to 
rules, and are in fact conditional expressions. The antece- 
dent of a conditional expression is a Boolean expression, 
but not an inquiry or absence test. The consequent of a 
conditional expression is another expression, not an asser- 
tion or deletion. Thus, conditional expressions (and func- 
tion bodies derived from them) are free of side effects. As 
the factorial example illustrates, functions may be declared 
recursively. Iterative constructs are not defined. 

F. PEOCIDUEES 

A typical invocation sequence for a rule begins when a 
tuple is added to a relation. The tuple is associated with 
an agent — the object or process that made the assertion — and 
the agent often expects a group of rules to execute as a 
result of this assertion. Finally, the agent may expect a 
value or object to be returned. 
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To illustrate this, consider the assertion of a tuple in 
the Request relation. Such a tuple aay be <a, r>, where the 
object a is a relation representing the agent, and the 
object r indicates the resource desired. This assertion was 
made to trigger the following rule: 

if *Reguest{a, r) , *Avail (r, id) -> 
a (id) . 

In this example, the relation a is used as a mailbox to 
receive a response from the server rule. The assertion of 
the tuple <a, r> is similar to the creation of a conven- 
tional activation record, and the mailbox a is similar to 
the activation record of the caller. 

The assertion a (id) places the desired response — a 
resource identifier — in the relation belonging to the 
requesting agent. When this response appears in the mailbox 
relation, the requesting agent may extract the result and 
continue its computations. The mailbox relation serves as a 
synchronization and value-returning mechanism. 

In an event-driven system, such a calling sequence would 
be a common usage pattern. This is recognized by the inclu- 
sion of a calling mechanism within the language. The above 
sequence could be initiated by a synchronous call. Consider 
the following rule; 

if *InitProc (p) , *Eequire(p, r) , -lAllocate (p, x) -> 
Allocate (p. Request {r}) . 

The Request expression in this example is a synchronous 
procedure call. Its effect is the automation of the mailbox 
handling of the previous rule. The call Requester} will be 
translated by the system into an assertion Request (a, r) . 
The object a is a system- supplied relation that will receive 
a response from rules firing as a result of the assertion. 
When a tuple is added to this relation, the tuple is 
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returned as the result of the procedure call in the expres- 
sion where the call was invoked . 

The procedure call as shown in the preceding example is 
similar to the function invocation described earlier. Both 
invocations may be used in expressions, returning results 
that are incorporated in expressions. The underlying mecha- 
nisms of the function and procedure call are different, 
however. In particular, the procedure call relies on the 
use of rules to describe its actions, and therefore relies 
on side effects. 

The server rule in this example may be triggered by 
either an assertion cr procedure call involving the Request 
relation. There is nothing about the form of the rule that 
indicates its use in procedure calls. By convention, 
however, such rules must use the leftmost member of a tuple 
in the enabling relation as the receiver of the response. 

The value returned by a procedure call does not have to 
be used in an expression. In the following example: 

if *Function ( job, c) , -.CodeTable (c, def) -> 

Display [’’Illegal function code”} 

an assertion to the Display relation is assumed to eventu- 
ally cause the message to be displayed at the user's 
terminal. The value returned by the calling mechanism is 
used for synchronization only, and is otherwise ignored. 

G. SEQUENTIAL CONTBCl 

In the preceding examples, no particular order was 
assumed for the evaluation of conditions in the antecedent, 
and no order is assumed for the execution of the actions in 
the consequent. These actions may be considered to be 

asynchronous and concurrent. This situation becomes even 
more unstructured when a collection of rules is being 
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considered for evaluation. Once again, no evaluation order 
is assumed. 

The sequential block provides a mechanism for the 
programmer to specify an explicit order for rule evaluation. 
This is shown in the following; 

if *Eequest(a, r) , -iAvail(r) -> 

£ -> Display {"Hai tin g for resource..."}; 

if *Queue(r, 1) -> 

Queue (r, cons[a, 1]); 

} 

The effect of this rule is to display a message and to add 
the requesting agent to a queue for the desired resource. 
The sequential block guarantees that the rules within the 
O's will be evaluated in the order shown. 

As the example indicates, the variables bound in the 
antecedent retain their bindings in the sequential block. 
The blocks may be nested, with the bindings of free vari- 
ables extending to inner blocks. 

In this example, the antecedent is omitted in the 
Display rule- This is equivalent to a true antecedent. 
When writing such rules, the notation may be shortened to: 

Display £x} 

which is equivalent to; 

if TRUE -> Display £x} . 



H. CONTROLLING THE NAME SPACE 

The previous descriptions give a simple mechanism for 
the binding of logical variables- The rules nay be summa- 
rized as; 
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• The scope of variables bound in an antecedent extends to 
the consequent for a given rule. 

• If sequential blocks are nested, oindings made in outer 
blocks extend to inner blocks. 

The previous examples have suggested a more global binding 
mechanism, as indicated in the use of relation names. The 
Request relation name is globally bound in this manner. The 
mechanism through which global names are managed is the 
directory. 

A directory is a named collection of pairs, <name, defi- 
nition>, where the name entry is a character string and the 
definition is an object or value representation associated 
with the name. The directory may be thought of as a named 
symbol table. 

MacLennan [Ref. 14; pp. 34-35] describes a directory 
structure with two partitions: public and private. Names 
defined in the public partition are globally visible to 
agents other than the owner. Names defined in the private 
partition are visible only to the owner. 

A simple elaboration of this mechanism provides a flex- 
ible partitioning scheme. The public and private partitions 
are associated with named directories. These directories 
are organized into named classes, not necessarily disjoint. 
In addition, there is a notion of a "current directory" 
similar to that in UNIX. 

The context of a name, then, is determined by the 
current directory in which the name is defined. Rhen evalu- 
ating the binding of a name, the current directory public 
and private partitions are searched for an entry. If this 
local search fails, the public directories associated with 
the classes of the current directory are searched. The 
class structure defines a search path for variable lookup. 
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To illustrate these points, consider the definition of 
the Bequest relation of previous examples. Suppose the 
current directory is "ServerDat abase, " a member of the class 
"Servers." The relation is created and named by; 

Define {Private, "Request", NewrelQ}. 

The Define procedure call makes a <name, definition> entry 
into a directory partition. The Newrel£} procedure call is 
assumed to return a unique system identifier that represents 
a relation. The definition shewn, therefore, would create 
the relation and bind a name to that relation in the private 
partition of the current directory. 

Such a server relation would be of more general utility 
than a private definition allows. Before the relation is 
opened to broader access, an access control mechanism is 
necessary. 

This control is achieved by associating capabilities 
with each relation. When a relation is created with the 
NewrelQ procedure call, full capabilities are associated 
with the relation identifier. These capabilities include 
read, add, and delete. A public definition of the Bequest 
relation may be accomplished as follows; 

Define {Public , "Request", AddOnly {Request} } . 

The AddOnly procedure call references the system identifier, 
with full capabilities, that has been bound to the private 
name Request. A copy of this identifier is made with 
reduced capabilities but still referring to the same rela- 
tion. This new identifier is then installed in the public 
directory for general access. This technique of capability 
addressing is based on the werk of Dennis and Van Horn 
[Ref. 17]. 

Objects are created in a similar manner; 

Define {Private, "Jobi", Kewobj{}}, 
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The NewobjQ procedure returns a unique identifier to be 
associated with an object. Objects created in this manner 
have no intrinsic value associated with them, and there is 
no access control associated with their identifiers. 

I. A PEOGHAHMING SYSTEM 

The language elements described may be adapted to a 
general programming system. To simplify interaction with 
the system, [Bef. 14: p. 39] suggests the use of rules as a 
command language. 

While syntactically similar to production rules, these 
command rules are subject to a slightly different method of 
interpretation. If a user wishes to query the contents of 
the Allocate relation, this may be accomplished by: 

if Allocate (x) -> Display {x} . 

If analyzed as a production rule, however, this query would 
be a **fire forever” type. Rules such as this require a 
different method of evaluation: test, fire, and forget. 

The command rules represent the second class of rules in 
the system. The first class of rules is that of the produc- 
tion rules previously described. These rules are termed 
active rules. Active rules comprise a body of state tran- 
sition information that continuously monitors the relations 
referenced in their antecedents. Command rules are initi- 
ated by an event in the system, and only evaluated once. 
The initiating event in previous example was the entry of a 
command rule at the terminal. 

The active rules are distinct from command rules, yet 
the command rules provide the interactive interface between 
the user and the system. The two categories are bridged 
with the rule denotation. 
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A rule denotation is a syntactic representation of rules 
as data. A potential active rule may be described; 

Define {Private, "RequestRules" , 

« 

if *Reguest(a, r) , *Avail{r) -> 

Allocate {a, r) , a (r) 

» 

}. 

The denotation is expressed betvjeen « >>'s, which is inter- 
preted as "parse but don’t evaluate." This definition binds 
the parse tree associated with the server rule to the name 
’’ReguestRules" in the private directory partition. 

A rule denotation bound in this manner is a data struc- 
ture subject to manipulation by the system. To make the 
transition from this passive status to active status, the 
rule denotation is activated: 

Activate{ServerRules} . 

At this point, the rules expressed in the denotation are 
moved to active status and enter a continuous test-fire 
cycle. 

This process is similar in many respects to program 
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III. DESIGN ISSOES AND GOALS 

A. THE ARCHITECTORE OF BOLE-BASED SYSTEMS 

Omega is a production-rule system. Davis [ Bef . 18: p. 

301] describes these systems in terms of three components: 

• A rule base. Omega's set of active rules. 

• A database. The set of relations and their contents. 

• An interpreter. The mechanism for rule selection and 
execution. 



B. ROLE SELECTION AND CONFLICT 

The control cycle of the interpreter processes rules in 
a continual recognize/act cycle. The recognition phase 
consists of selection and conflict resolution [Ref. 18: p, 
325]. 

Omega uses a forward-chaining method for rule selection. 
This method, described in the examples of the previous 
chapter, compares the antecedent of the rule to the data- 
base. A rule is selected when an appropriate match is 
found . 

In general terms, production systems produce a conflict 
set for each recognize/act cycle [Ref. 18: p. 325]. The 
conflict set consists of all active rules whose antecedents 
are true given the current state of the database. In the 
Omega system, the resolution of the conflict set is simple. 
For a given cycle, each rule within the conflict set will be 
tested and, if its conditions are true, will fire. The 
order in which the rules in the conflict set are tested is 
not specified. 



32 



The rules of Omega are indivisible once they are 
selected [Bef. 14: pp. 19-20]. To illustrate this point, 

suppose the following rules were active: 

if ^Request (a) -> Allocate (a. Red). 

if *Reguest(a) -> Allocate (a. Blue). 

Under this selection strategy, only one of these rules will 
fire (assuming there is only one tuple in Request) . The 
indivisible nature of rule evaluation guarantees at least 
mutual exclusion for rules such as these. Since the evalua- 
tion order for these rules is not defined, a more explicit 
antecedent would have to be designed to establish conflict 
priorities. 

The rule selection and conflict strategies support a 
powerful execution mechanism. Using this approach, the 
procedural information of the system is sensitive to the 
state of the database, and responds accordingly. This 
behavior is more complex than a procedure-oriented system, 
where the thread of execution control is more closely tied 
to the procedural code organization. 

The complexity of rule testing has performance penalties 
associated with the precision of rule selection. By preci- 
sion, we refer to the number of rules whose antecedent 
conditions are true compared to the number of rules selected 
for testing. The most inefficient and most obvious level of 
precision is to scan the entire rule base on every cycle. 
We call this a global sweep strategy. At the opposite 
extreme is a selection strategy that produces only 
"successful" rules for test. 

C. PATTERN-HATCHING 

At the heart of the rule evaluation process is pattern- 
matching. Given the form of a rule: 

if B(e1) 
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a description the pattern-natching process for each candi- 
date tuple X in R is: 

match[ X, el ]: 

if x=Nil and e1=Nil 
return TRUE 

else if x=Nil or e1=Nil 
return FALSE 
else if el is an atom 
if el is unbound 
bind[e1, x] 

history ;= cons[e1, history] 
return TRUE 
else if el = x 

return TRUE 

else 

return FALSE 

endif 

else if ma tch[ f irs t[ X first[e1]] 

return match[ rest[ x ], rest[e1]] 

else 

return FALSE 

endif 
end match 

This description assumes a LISP-like list representation for 
tuples. 

This pa ttern- matching process is expensive. 

Incorporating this method at the heart of the interpretation 
cycle presents a significant design challenge. 
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D. HOBE CONVENTIONAl ISSUES 

Besides these unusual design issues. Omega is subject to 
the same design requirements as more conventional languages. 
These include: 

• A parser and lexical scanner for command/rule input. 

• A procedure- oriented evaluation component for applica- 
tive expressions. 

• A flexible symbol table mechanism for the support of 
directories. 

• Dynamic typing. 

• Dynamic memory allocation and reclamation. 

E. DESIGH GOALS 

The design goals for the prototypes are grouped into the 
areas of feature implementation, relation representations, 
efficiency, and evaluation. 

1 Impl emen tati on 

The major objective in this work was the construc- 
tion of working prototype interpreters for the language. A 
progressive schedule was developed that sought to implement 
the following features: 

• Canonical Rules. This phase includes the development of 
the inquiry, absence, assertion, and deletion functions 
for basic rule interpretation. 

• Function definition and evaluation. 

• Procedure calls- 
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• Cancel operations. 

• Sequential blocks. 



2. Re lation Represent at io ns 

Relations and the operations defined on them are the 
central components of the Omega system. To support flexi- 
bility in relations, a variety of representations is desir- 
able. Such representations could range from a simple list 
structure to a relational database management system (DBMS). 
To reduce the problems associated with multiple representa- 
tion, the relation interface must be clear: an abstract 

data type, with primitive operations defined for data 
access. 

3- Effi cie ncy 

The Omega language was developed as a general- 
purpose language, capable of prototyping programming envi- 
ronments and a variety of system-level functions. This 
orientation makes execution efficiency an important imple- 
mentation issue. The goal was to obtain a level of 
efficiency comparable to a LISP system. 

Efficiency was considered mainly in terms of execu- 
tion speeds. In those cases where a space-f or-time trade- 
off was available, it was made. 

^ • Eva luat i on 

The final goal for the prototypes was evaluation. 
This evaluation centered on performance: how control strat- 

egies and data structures affect execution time. A second 
evaluation area was to determine the utility of language 
features through programming experience. 
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I¥. A LISP IHOTOTYPE 



A. "HHI LISP? 

The design issues for Omega led to the decision to write 
a quick prototype for the exploration of high-level design 
decisions. The high-level corcerns were the interpreter 

organization, selection strategies for rules, and the repre- 
sentation of objects, relations, and directories. 

Efficiency was not a design goal for this prototype. 

Franz LISP was selected as the initial prototyping 
language. This selection was made for the following 

reasons: 

• Availability. Franz LISP was available on the VAX 
11/780 system being used for this work. Ke were 
familiar with Franz LISP, and the implementation is 
well-done. The system includes a reliable interpreter, 
compiler, and debugging package. 

• Symbolic facilities aid in pa ttern- matching . The heart 

of the Omega design is the pattern- matching process. 
The symbolic manipulation facilities of LISP allow these 
algorithms to be programmed quickly. 

• Dynamic typing. The dynamic typing of LISP corresponds 
well with the typing of Omega. 

• Memory management. Memory management is transparent 
under LISP. While these issues can impact heavily on 
system performance, they are complex and distracting to 
early prototyping. 

• Debugging. The debugging facilities of Franz LISP are 
excellent, and superior to any other development 
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environment available at the time. In a prototyping 
project, extensive debugging is essential to cope with 
constant design and coding changes. 



B. OEGANIZATION 

The interpreter is organized like a classic LISP inter- 
preter. The organization is based on the description given 
in Chapter 11 of [Eef. 19]. 

The top level consists of a r ead-evaluate-sweep loop. 
The read function is a command rule parser. Commands are 
entered at the terminal, parsed, and an instruction list is 
generated. ' This instruction list is passed to the evalua- 
tion function for execution. The sweep function processes 
any active rules that are ready to fire after the actions of 
the r ead-evaluate phases are complete. 

C. THE LEXICAL SCANHEE AND PAESEE 

The reader consists of a lexical scanner and parser. 
Instead of evaluating input as LISP expressions, the reader 
accepts free-format input using the Omega grammar. 

1 . The Lexical Scanner 

A character reader function is used to pass a list 
of characters to the scanner. This reader function uses the 
character input facility of Franz LISP [Eef, 20: pp, 
5. 6-5.7], As each character is read, it is added to an 
input character list. The complete character list is 
passed to the scanner.. 

The scanner processes the input character list to 
recognize tokens. Ehen recognized, a character list is 
compressed into a token (LISP atom) using the implode func- 
tion [Eef. 20; p. 2.11], The final output of the scanner is 
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a list of tokens built up in this manner. It is this 
complete list of tokens that is passed to the parser. 

The token classes consist of identifiers, constants, 
and delimiters. Constants are limited to integers and 

strings. Once a constant token is recognized and 

constructed, a denotation function transforms the symbol 
into a LISP integer or string atom. 

The separation of the scanner from its supporting 
reader function allows the same routines to read from 
multiple sources. Two reader functions are used: one for 

console input and one for file input. The file input func- 
tion is used to support command rule entry from text files, 
similar to the load function of Franz LISP [Ref. 20: p. 

5.5]. 

When receiving console input, the reader needs to 
distinguish the end of input for a command. Successive 
carriage returns are recognized as this termination 

condi ti on. 

2 . The Pars er 

A single-pass, recursive descent parser is used to 
process the token list produced by the scanner. As a 
construct is recognized, an operator symbol is created 
which, along with its operands, is added to the parser's 
output list. The parser receives a token list as input, and 
returns an operator/operand list as output. 

The output list for the parser is a simplification 
of the abstract syntax for the language. Consider the 
following input: 

if *R1 (X) , R2 (X) -> R3 (X) . 

This rule is reduced to a token list by the scanner and 
input to the parser. The parser output for this rule would 
be the following LISP expression: 
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( 

(CANCEL (INQUIRY (VAR "R1") (TUPLE (VAR "X") ) ) ) 
(PRESENT (INQUIRY (VAR "R2") (TUPLE (VAR "x")))) 
(ASSERT (VAR ''R3'') (TUPLE (VAR "x"))) 

) 

The sublists preceded with the symbols CANCEL, PRESENT, and 
ASSERT are termed instruct! ons . A list of these instruc- 
tions is produced for every rule. 

These instructions correspond to the basic actions 
that the interpreter must perform. Besides the three 
instructions shown, this prototype produces similar instruc- 
tions for the deny operation (DENY) . 

Subordinate instructions are created for operand 
generation and evaluation. In the preceding example, the 
sublists headed by INQUIRY, TUPLE and VAR fall into this 
category. Other subordinate instructions are included for 
constants (CON) , rule denotations (DENO) , and function 

application (APL). 

A subset of the original Omega grammar is recognized 
by the parser. The intent was to allow the interpreter to 
evaluate the simplest canonical form of rules, which uses 
present/inguiry tests, absence tests, assertions and 
denials. 

The Omega grammar described in [Ref. 14] makes no 
syntactic distinction between the antecedent and consequent 
of a rule. Thus, a rule would be written: 

R1 (X) , R2 (X) -> E3 (X) , R4 (X) . 

The convention of allowing the •'->'• to be omitted in a 
command rule requires an indeterminate lookahead to decide 
whether the antecedent or consequent portion of the rule is 
being parsed. If the "->" is omitted, every token in the 
input list must be examined. 
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This problem is solved by a pre-scan of the token 
list before parsing. If the token list doesn't contain the 
token, it is inserted at the beginning of the list. 

D. ROLE EVALUATION 

The interpretation of a rule is done by an iterative 
execution function and a subordinate recursive evaluation 
function. The execution function steps through the instruc- 
tions in a rule and passes them to the evaluation function. 
This separation into iterative and recursive functions is 
done to facilitate backtracking. 

The evaluation function returns a value of "true” or 
"false." If an instruction is evaluated "false," the execu- 
tion routine resets any temporary bindings associated with 
that instruction's predecessor, then attempts to re-execute 
the predecessor. The rule fails when this process backs up 
to the initial instruction. It succeeds if all instructions 
succeed. 

At the level of the execution function, there is no 
distinction between the coaditicns of the antecedent and the 
actions of the conseguent. Backtracking is only meaningful, 
however, in the antecedent portion of the rule. Therefore, 
the evaluation function always returns "true" for instruc- 
tions generated from the consequent of a rule unless an 
error is detected. 

An instruction history list (a stack) is maintained to 
support backtracking. If a backtrack is required, the 
pointer to the predecessor instruction is popped from this 
list. If the instruction succeeds, the pointer for the 
instruction is pushed on the list. 

A binding history list (another stack) records the 
logical variable bindings being made as each instruction is 
evaluated. If an instruction fails, the bindings of its 
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predecessor are popped from the binding history list and 
undone. If an instruction succeeds, any free variable bind- 
ings made during its evaluation are pushed on the binding 
history list. 

The cancel operation requires the generation of a DELETE 
instruction should the cancel evaluate as ’’true." A delete 
list is maintained for this purpose. To support back- 
tracking, the delete list is checked for duplicates before 
adding instructions. The instructions in the delete list 
are passed to the evaluation function after all the instruc- 
tions for the rule have successfully executed. 

1 . Instruction Eva lu ation 

The instruction evaluation function performs a 
direct interpretation of the instructions produced by the 
parser. The steps of the function are simple: 

Eval[ 1 ]: 

return Op [ Eval[ o1, o2, . . . , on ] ] 

where Op is the operator of 1 and 
<o1, . . ., on> are the operands of 1 

end Eval. 

The function recursively evaluates the operands of an 
instruction, then applies the instruction ’s operator to the 
result. To support this organization, a LISP function is 
defined for each operator. 

2 • The Applic ativ e C ompon ent 

The applicative component of Omega is simply 
supported by function definitions in LISP. Such functions 
are invoked by the API operator, which is passed the func- 
tion name and its arguments. These symbols are directly 
interpreted by LISP, and a result produced. 



This applicative mechanism bypasses some important 
issues which a non-LISP implementation must consider. These 
issues include function definition at the rule level and the 
interface between the object-oriented and applicative inter- 
preter mechanisms. 

The simplicity with which new functions can be 
defined to support the Omega interpreter gives this imple- 
mentation a strong reliance on functions. Consider the 
implementation of a rule for Display: 

if *Display (x) -> 

Null (Print[ x ]) . 

The function call Print£x] is translated directly to the 
LISP print function. Null is a dummy relation whose only 
purpose is to allow the print function to execute. 

In the above example, the use of the Print function 
is inconsistent with the philosophy behind the applicative 
component of Omega. The LISP print results in a side 
effect, and is therefore not a pure applicative expression. 

The print mechanism is more accurately modeled 
through relations. A functional implementation is forced in 
situations such as this to allow access to LISP definitions. 
The consequence of this "bending" of the semantics of the 
language is shown by the appearance of awkward constructs 
such as the Null relation. 

3 . Objects 

An object in Omega is used as a place-holder in 
relations. To fill this role, the fundamental character- 
istic of objects is uniqueness. This was easily inplemented 
using the gensym function of Franz LISP [Ref. 20: p. 2.8], 
which returns a unique symbol each time it is called. A 
function to create new object identifiers needs only to make 
successive calls to gensym. 
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^ • Relati ons 

Relations are represented as objects which have an 
associated list of tuples. The relation object identi- 

fiers are created through the gensym mechanism previously 
described. A value is bound to the symbol using the set 
function of LISP. 

To illustrate this representation, consider the 
following sequence of command rules: 

Define (root, "R1", Newrel[ ]) . 

El ("a", "b", "c"). 

R2("x", "y", "z"). 

The Newrel[ J function returns the object identifier for the 
new relation. After the assertions, the relation R1 
consists of the following: 

( 

njjii lie") 

^ll^n llyll 

) 

The relation is a list of tuples, each of which is a list. 

With the list representation for relations is a set 
of management routines. These routines are match, add, and 
delete. 

The match function provides the mechanism for 
pattern-matched inquiries. The function is constructed as 
follows : 

match[ RelationName, Tuple, Index] : 

if Index = Nil 

R := get binding of Relation Name. 

else 

R := Index 

endif 

while R <> Nil 
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if ■ ma tch_e'jual[ f irst[ R ], Tuple] 
return E 

else R : = rest[ E ] 
end while 
return FALSE 
end match 

The ioatch_egual function is a nodified version of a recur- 
sive list equality test. A modification is required for 
unbound variables. The algorithm is: 

match_equal[ R 1 , E2 ] : 

if R1=Nil and R2=Nil 
return TRUE 

else if Rl=Nil or R2=Nil 
return FALSE 
else if R1 is UNBOUND 
return TRUE 
else if R 1 is an atom 
return E1=R2 

else if ma tch_equal[ f irst[ R 1 j, first[R2]] 

return match_equal[ rest[ E 1 ] , rest[R2J] 

else 

return FALSE, 
end match_equal. 

The match function performs a linear search of the 
relation. Each tuple is selected and tested until a match 
is found or the list of tuples is expended- The index 

parameter passed to the match function indicates the point 
in the relation where the search is to begin. This indi- 

cator is non-nil when the match is being requested on a 
backtrack attempt. 

The match_equal algorithm is similar to the pattern- 
matching algorithm discussed in the previous chapter. In 
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match_egual, however, no variable binding is done. Instead, 
variable bindings are made after match_egual returns its 
result. 

The add function places new tuples at the beginning 
of the relation list, making the relation list a LIFO struc- 
ture. The delete function removes a tuple directly from the 
relation list. 

5 . Bind ing 

Variable binding is controlled by symbol tables for 
temporary and global bindings. These symbol tables are 
implemented as association lists, and are manipulated 
through the following management routines: 

• Add. Install a symbol and its definition in the symbol 
table. 

• Delete. Remove a symbol and its definition. 

• Lookup. Given a symbol, search the table and return the 
def inition. 

The use of association lists for symbol table repre- 
sentation is not the most efficient method provided by LISP, 
but dees offer some advantages. The representation is 
simple, and the table contents can be easily inspected 
during debugging. Also, there is a close correspondence 
between these association lists and the structure chosen for 
relations. 

The correspondence between symbol tables and rela- 
tions allows the direct implementation of directories as 
relations. The directory provides an environment which 
binds variables during rule evaluation. 

To support the use of multiple directories, the rule 
structure was expanded to include an environment pointer for 
each rule. This environment pointer represents the 
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directory to be used for variable lookups. A rule, then, is 
represented as a pair: <ep, ip>, with environment pointer 

(ep) and an instruction pointer (ip) . This representation 
is called a closure, and is a technique used to simulate 
static variable binding in LISP systems [Ref. 19; pp. 

436-37]. 

To support temporary bindings made by pattern- 
matching, a local symbol table is used. The evaluation of 
variable bindings follows the following sequence: 

• When a rule begins execution, a global environment 
pointer is set to the environment pointer for the rule. 

• To evaluate a variable, the local symbol table is 
searched for a previous definition. If not already 
defined, the directory referenced by the environment 
pointer is searched for a global binding. If globally 
bound, the variable and its definition are installed in 
the local symbol table. 

• If not defined in the local symbol table or in the 
rule’s directory, the variable is considered unbound. 
This is represented by the installation of a special 
"unbound" definition in the local symbol table. 

Variable binding details are external to the rela- 
tion management functions. Before passing a tuple to the 
natch function, lookups are made in the local symbol table 
and variables replaced by their definitions. The match 
function accepts this tuple as input, and returns a pointer 
to the corresponding relation tuple if a match is found. 
Tree variables become bound by having their match counter- 
parts added as definitions in the local symbol table. 

The isolation of the relation match function from 
variable binding simplifies the interface between the rela- 
tion management routines and the evaluation function. This 
simplistic approach is flawed, however. 
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Consider the following rule: 
if *E1 {x, X, y) -> R2(x, y). 

Assume the relation El only contains the tuple <1, 2, 3> . 

Using the match algorithm previously described, the pattern 
<x, X, y> would successfully match against <1, 2, 3>. To 

prevent such an error, the match algorithm must take tempo- 
rary bindings into consideration. This requires an exposure 
of some of the details of the binding mechanism to the rela- 
tion management routines. 

E. CONTROL 

Active rule interpretation occurs during the sweep phase 
of the interpreter’s top level. This prototype uses the 
simplest possible control strategy for rule selection: each 

active rule is tested on every cycle. Active rules are 
maintained in a list, and the execution function is mapped 
to each of the rules. In LISP terms, this is written: 

(mapcar • (lambda (rule) 

(exec (car rule) (cadr rule))) 
ActiveEuleList) ) 

The lambda function splits each active rule into its 
instruction and environment components. 

After each cycle, the above sequence returns a list of 
results from each application of the execution function. 
The result for a cycle appears as: 

(t t nil nil t nil . . .nil) 

where each "t" response comes from a successful rule execu- 
tion. The sweep phase will continue to cycle through the 
active rule list until all rules return a "nil" response. 
At this point, the active rale list is in a quiescent state. 
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and additional cycles will not produce any new state 
informa tion. 

F. EEROE COHDITIONS 

Binding requirements differ as rule evaluation proceeds 
from the antecedent instructions of the rule to the conseq- 
uent instructions. These requirements constitute a signifi- 
cant source of error. 

In the antecedent, the members of a tuple may or may not 
be bound. An unbound variable at this point is not an 
error, unless the variable is involved in an applicative 
expression. In the consequent cf a rule, all variables must 
be bound. Unbound variables at this point are reported as 
an error. 

The binding for relation names is more strict. Given a 
left-to-right evaluation of instructions, each relation name 
must be bound before its evaluation. 

Consider the rule; 

I 

if *E(x), x(y, E) -> . . . 

The evaluation of relation R occurs first. The variable B 
must be globally bound, or an error will occur. In 
contrast, the variable x is boucd in the R (x) inquiry. Its 
later use as a relation name is valid. 

The requirement that relation names be bound is an 
implementation restriction. A more general mechanism would 
allow a sequential search of all relations in the database 
for trial bindings of relation tames. This would extend the 
free variable binding process previously shown only for the 
tuples in a relation. 

A simple error-handling approach is used in this system. 
When an error is detected, a message is displayed and the 
interpreter continues with the evaluation of the next 
instruction. 



A BOOT SYSTEM 



G. 



After the implementation of the basic rule interpreter, 
it was necessary to identify a minimum set of definitions to 
support a working system. When such a system becomes opera- 
tional, additional features can be added through rules 

defined in Omega. 

The foundation of the naming mechanism is the Define 
relation. No rules, relations, or constructs may be added 
to the system without the use of Define. To accommodate 
names that are added as the system grows, a minimum of a 
single directory is necessary. 

In this prototype, a root directory, defined in LISP, 
contains the initial bindings required by the interpreter. 
The root directory initially contains the bindings for the 
Define relation and the active rule list. This directory 
also contains a reference to itself: a binding for the name 

"root . " 

To support the definition cf system functions in LISP, 
the names of these functions are pre-defined at the time of 
system initialization. 

The initial root directory appears as: 

(setg root ’ ( 

("Root" root) 

("ActiveEules" ActiveEules) 

("Cons" cons) 

("First" car) 

("Rest" cdr) 

("Append" append) 

) 

This association list binds the Omega names to the appro- 
priate LISP symbols. 
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When the interpreter begins execution, the following 
events occur: 

• The root directory is loaded into LISP. 

• An Omega initialization file is parsed and evaluated. 

• The interpreter begins its read-evaluate-sweep cycle. 

The initialization file contains Omega command rules 
that allow the implementation of system functions with 
rules. These rules are defined by the following assertions: 

Root ("Activate" , Newrel[ ]) . 

ActiveRules (Par se[ Fread [ "sysgen. rul" ] ]) . 

The assertion to the ActiveRules relation initializes the 
system’s set of active rules to those contained in the file 
"sys gen .rul. " These initialization rules consist of: 

if *Define(dir, name, def) -> dir (name, def ) . 

if *Activat e(newrules) , ^ActiveRules ( oldrules) -> 
ActiveRules (Append[ ol drules, newrulesj) . 

These rules and definitions are sufficient to set up a 
minimum system. As shown by the rules for Define and 
Activate, it is possible to express system functions as 
rules. To expand these functions, more rules may be defined 
and added to the active rule list. 

H. LZSSOHS LEARNED 

This early prototype was instructive, both in those 
functions which worked well a rd in those functions which 
performed poorly. 

The major benefit was the implementation of a top-down 
design. The read-evaluate-sweep cycle demonstrated that a 
recursive, LISP- like interpreter design was useful for 

Omega . 
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The prototype implemented a simple list representation 
for relations, and assisted in the identification of primi- 
tive operations required to manipulate relations. Of 
particular interest was the pattern-matching algorithm. 
While the implementation was flawed, the basic algorithm was 
useful in the follow-on prototype. 

The iterative backtracking algorithm was more complex 
than necessary. The stacks used to support backtracking 
suggested a recursive algorithm as a possible alternative. 

The design chosen for the parser was a poor one. The 
steps of creating a character list, then a token list, and 
finally an instruction list, were time consuming. The 
requirement to scan the token list for the presence of the 
”->” token worsened the already poor performance of the 
parser. 

The interpreter used the crudest possible control 
strategy, and tested every rule on each iteration of the 
sweep cycle. This control strategy has the obvious advan- 
tage of simplicity, but the performance is unacceptable. 
The control strategy, together with the slow parsing speed, 
resulted in a sluggish system response, even with a small 
number of active rules. In one test case, the parser 
required 13 seconds to process a 33 line rule file; with an 
active rule list of about 20 rules, a simple Display command 
took 2 seconds to execute. 

It was anticipated that the performance of this proto- 
type would be poor, and so it was. This is not a reflection 
of LISP as an implementation language. No attempt was made 
to write efficient LISP, and substantial improvements can 
probably be made. Potential areas for improvement are: 

• An improved parser. The character i/o in Franz LISP 
lends itself to the inefficient implementation used in 
the prototype. A possible improvement would be a 
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scanner and parser written in C, and integrated into 
Franz LISP as a foreign function [Ref. 20: pp. 8.4-8. 8]- 

• Improved control strategies. More precise rule selec- 
tion strategies impact heavily on performance. 

• More efficient LISP. Franz LISP offers alternatives to 
the simple list structures used in this prototype. An 
analysis of the prototype performance could be performed 
to pinpoint areas for LISP code optimization. 

The LISP prototype was intended to be a throw-away 
implementation. While numerous improvements are possible in 
this prototype, the performance of the LISP interpreter 
becomes a final limitation. An implementation in a lower- 
level language offers the potential for data structures, i/o 
facilities, and memory management techniques that are more 
closely tuned to the requirements of Omega. 

An important decision in the life of a throw-away proto- 
type is when to stop. This prototype was abandoned after 
the implementation of a limited but fundamental set of 
features. The prototype was revised numerous times, but 
with a minimal expense in coding time and implementation 
complexity. While many aspects of the interpreter design 
changed in the follow-on i mple irenta tion , the contributions 
of this prototype to the next were substantial. 
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V. A FOILOW-ON IMH mentation IN C 



A. WHY C? 

The second prototype was written using the C language, 
although other alternatives were available. The decision to 
to use C was based on the following; 

• High level control structures. The language has a 
reasonable set of control structures that support 
modular programming. 

• Simple but flexible data structuring. C supports a 
limited but flexible set of data types and constructors 
that are well-suited for interpreter implementations. 
The bit-level operations and weak data typing provide 
opportunities for space and speed optimizations. 

• Recursion. C is a recursive language, and many of the 
algorithms explored in the LISP prototype were easily 
translated into recursive C versions. 

• Integration with UNIX. As with the LISP prototype, the 
follow-on was developed on a VAX-11/780, using Berkeley 
UNIX (BSD 4. 2) . No language is better suited to UNIX 
than C, and vice versa. The operating system provides 
many features that directly support access to system 
routines and variables. The numerous software develop- 
ment tools available on a UNIX system are largely 
intended for use by C programmers. 

C is not a perfect implementation language by any means. 
The availability of low-level cperations and type coercion 
provide a dangerous source of error and confusion. The 
terse syntax is difficult to read for those unfamiliar with 
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the language. Finally, C’s strict use of c all-by- value 
forces a proliferation of pointer usage, complete with a 
flood of subtle errors resulting from pointer abuse. 

Despite its limitations, C is a tool well-suited to its 
environment. 

B. CHANGES TO SYNTAX AND SEMANTICS 
1 . An Ante ced ent Keywo rd 

The previous chapter discussed the problem caused by 
the optional sign in the Onega syntax. The problem was 

circumvented in this implementation by the use of the 
keyword "if” to signify the beginning of the antecedent of a 
rule. A one token lookahead is sufficient to detect this. 

The original Omega syntax uses the "if" keyword to 
signify a constraint. Thus a rule would be written; 

*E1 (x) , *R2 (y) , if X > y -> . . . 

Syntactically, the keyword is net necessary to distinguish a 
constraint. Therefore, the use of the keyword was modified 
to solve the lookahead problem. Using this modification, 
the rule is written: 

if *Rl (x) , *R2(y), x > y . . . 

The semantics are unchanged. 

2 • De not at ion s 

The delimiters for a rule denotation were originally 
asymmetric quotes. This was modified to the <<• . .>> 

construct shown in previous chapters. This syntax was 
selected to add greater visual emphasis for rule 

denotations. 
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3. 



Rule Se pa r ators 

A small but important modification was made to the 
use of the period and comma as delimiters. MacLennan uses 
the semi-colon to separate rules within a sequential block, 
and a period is used for the separation of rules in a deno- 
tation. This distinction is made to emphasize the sequen- 
tial nature of the block in comparison to the concurrent 
nature of the rules within the rule denotation [Eef. 14: p. 
23]. 

This distinction was altered to solve the command 
rule termination problem. Rules are always separated by 
semicolons; a period indicates the end of the current 
command rule input. This replaces the dual carriage return 
termination of the earlier prototype. 

This problem results from the use of rules as a 
command language. Rules tend to span multiple lines, so a 
simple end-of-line termination is not sufficient to indicate 
the end of input. Two alternative solutions to this problem 
are: (1) terminate a multi-line command with a continuation 
character, or (2) use a special character to signify the end 
of input. 

The latter technique was selected, with some loss of 
the useful syntactic distinction between denotations and 
sequential blocks. It is hoped that the remaining distinc- 
tions between the two constructs, <<>>*s vs. {} *s, are 
sufficiently different to serve as a reminder of the differ- 
ences in semantics. 

4 . Parameter Lists 

The original syntax for a function call was similar 
to the form of an assertion or an inquiry. Thus a rule 
would appear as: 

*R1 (X, y) -> R2(cons(x, y)). 



56 



The square bracket notation for function parameter lists was 
selected to provide an obvious distinction between function 
calls and other non-applicative forms in the language. The 
square brackets also denote lists, with the similarity 
emphasizing the semantic connection between these 
constructs. 

A similar modification was made for the procedure 
call, where curly braces denote the parameter lists. This 
syntax appears unusual, and the procedure call mechanism is 
unusual. The semantic similarities between the procedure 
call and the sequential block, both of which provide some 
degree of control on the otherwise free concurrency of 
Omega, is emphasized by their common use of curly braces. 

5. Condit io na l E xpressi ons and Function Definitions 

The introduction of an applicative component into 
the language required syntactic extensions. These exten- 
sions were centered around the conditional expression, which 
is illustrated by the following rule: 

if *R1 (X) -> H2 ( if x<3 -> "YES" else "NO" ). 

The value of the assertion is determined by the conditional 
expression. 

Given the form of the conditional expression, a 
function declaration can be formed by giving the function 
name, parameter list, and body (a conditional expression) ; 

fn Max[x, y]: ifx>y->x else y. 

Syntactically, a function declaration may appear anywhere a 
command rule would appear. 

The form of the conditional expression is a modifi- 
cation to the original syntax of the rule, with restrictions 
to prevent side effects. 
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6 . An Re s ponse for Command R ules 

A syntactic change was made to allow expressions at 
the same level as assertions. This modification allows the 
entry of the following command rule: 

if *R1(x) -> X. 

When this rule is evaluated, the binding of x is "returned" 
by the rule. If this binding is printed by the interpreter, 
the necessity for ubiquitous "Eisplay" calls may be less- 
ened. This allows the command entry of expressions such as: 

2 + 2 * Sin[Pi/2]. 

where the interpreter returns the result. 

While this modification to the rule syntax is 
convenient for command rules, it provides some interesting 
semantic questions. Suppose the following is an active 
rule : 



if *R1 (X) -> 2 +2. 

What does the consequent of this rule mean? It involves no 
alteration of the database, but instead requires an expres- 
sion evaluation. 

The action may be described by the following equiva- 
lent form: 

if *R1 (X) -> Eval{"2 + 2"}. 

The expression is asserted to an implicit Eval relation, and 
the semantics of the procedure call apply. Note that, in 
general, the value returned by a procedure call used at this 
level is ignored. For command rules, this value may be used 
to indicate the result returned from evaluating a rule. 

Given this interpretation, consider the following 

rule : 



if *E1 (X) -> R2 (X) . 
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What is the "result" returned ty the assertion? A simple 
convention is that that the assertion of a tuple x to a 
relation R returns the tuple x as its result. 

7. Head/Tail Pat tern Spec ificat ion s 

A final added feature is a head/tail pattern speci- 
fication for lists, similar to that of Prolog [ Bef . 21; p. 
43]. This is shown in the following rule; 

if *El([h:t]) -> R1 (h) , R2 (t) . 

The [h:t] notation will match a list. The variable h will 
be bound to the head (first) of the list, the variable t 
will be bound to the tail (rest) of the list. 

The head/tail specification syntax is extended for 

tuples; 

if *R1(h:t) -> Rl(h), R2(t). 

This notation provides a pattern specification for tuples 
that is independent of tuple cardinality. This generality 
was not possible using previous constructs. 

C. DATA STRUCTDBES 

Data structures posed the major design challenges for 
this interpreter. The structures of particular interest 
were the representations for rules and for supporting the 
objects and values of the language. 

1 . A Uniform, Tagged List Struct ur e 

A list structure, similar to that of LISP, was selected for 
the representation of rules. This structure was selected 
for the following reasons; 
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• Rules are represented as binary trees. Using a list 
structure for rules allows a direct, recursive evalua- 
tion technique similar to that of the LISP prototype. 

• Omega needs lists. Lists provide a general constructor 
mechanism that is extremely flexible. In a pattern- 
matching language, list structures are essential if 
pattern-matching is to extend beyond character strings. 

• Uniform list structures sittplify design. Given that 

lists are desirable as a data type within the language, 
a simple set of list handling routines suffices for 
analysis and synthesis of data within the interpreter. 
Uniform list structure also allows storage allocation 
and reclamation to concentrate on a single unit: the 

list cell. 

A diagram of the basic cell structure is shown in 
Figure 5.1 The call has three fields: a tag field, a head 

field, and a tail field. Table I shows the types of values 
that each field may assume. 

The atomic values in this implementation are char- 
acter strings, signed integers, and objects. These atoms 
are represented by cells. The type of an atom, as with all 
cells, is determined by the value of its tag field. 

Integers have their values contained directly in the 
head field of a cell. Likewise, objects have their identi- 
fiers encoded in this field. The width of this field is 32 
bits, determined by the VAX 11/780 word size. 

Character strings have a pointer in the head field 
that references a contiguous block of string storage. 
Reflecting their C implementation, string storage areas are 
NULL terminated. On the VAX, NULL is represented by a zero 
value . 
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HEAD 


TAIL 
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Figure 5. 1 Cell Structure. 

A list cell coDtains pointers in both the head and 
tail fields. There are two classes of list cells; data 
list cells and operator list cells. These are distinguished 
by tag values. 

Data list cells are analogous to LIS? lists. They 
serve as data con structors. Operator list cells form the 
interior nodes of a binary tree representation for rules. 
Rules are transformed and evaluated as tree structures- The 
"instruction" concept of the prototype was dropped in favor 
of a more uniform approach. Figure 5.2 illustrates the 
parse tree for a simple arithmetic expression. 

This tagged structure simplifies evaluation at the 
expense of storage space. Individual tags are used for all 
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TABLE I 

Cell Field Values 



head field: 
Contents 


Commen ts 




cell pointer 


data and operator list 


cells 


string pointer 


string ceil 




integer 


integer cell value 
used for frame size in 


allocate op 


object id 


object cell — id is 32 


bit integer 


<blcck, offset> 


VAR cell--gives scope and offset 
within binding stack frame 


tail field: 
Contents 


Comments 




cell pointer 


data and operator list 
VAR cells and defined 
pointers to print name 


cel Is 

objects have 

3 


unused 


integer, string, and 
and most object cells 





primitive data types and for each construct (node) in the 
abstract syntax for rules. This results in a large number 
of tags: over 40 in the current implementation. A minimum 

of 6 bits, therefore, is re<guired to represent the tag of a 
node. Given the cell space requirements given in Figure 
5.1, approximately 11 percent of the system storage require- 
ment is needed for tags. (The actual percentage is somewhat 
less because of character string blocks and hash tables, 
discussed below) . 

2 . Objects 

As in the LISP prototype, objects are represented by 
a unique identifier. In this implementation a cell is 
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Expression: 2 + 4 * 5 




Figure 5.2 Tree Represent at icn for a Simple Expression. 



generated for an object and a r identifier embedded in the 
head field. Again the problem is how to manage the identi- 
fiers so that the are unique. 

The approach used is tc maintain an object count. 
Each time a new object is requested, the object count is 
incremented. If the control of object identifier allocation 
remains centralized, the objects are guaranteed tc be 
unique. 

The generation of identifiers this way leads to the 
issue of object identifier management. What prevents the 
system from running out of unique identifiers? What happens 
when the identifier space is exhausted? 
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A simple strategy is to ignore these problems alto- 
gether. How long can the system generate identifiers before 
it runs out? For a rough calculation, assume that a new 
identifier is generated every 10 milliseconds. The head 
field which contains an identifier is 32 bits, so assume 29 
bits are available (the use f cr the remaining 3 bits will 
be discussed shortly) . With these values, the identifier 
space would be exhausted in 229 x 10 milliseconds, or about 
62 days. The management of object identifiers is not a 
major issue in this system. Should a larger object identi- 
fier space be needed, additional bits could be provided from 
the tail field of the object cell. 

A small portion of the object identifier space is 
reserved for system use. In the current implementation, 
the first 64 object identifiers are reserved. The presence 
of a system object is easily detected by an examination of 
its identifier. 

3 . Hash Tables 

As in the LISP prototype, certain types of objects 

have values associated with them. These values are managed 

in this implementation using a uniform hash table mechanism. 

The hash table index is generated by a simple hash 
function. The algorithm is based on that given in [Eef. 22: 
p. 135]. The hash function receives a pointer to a cell as 

an argument, and returns the table index. The algorithm is 
as follows: 

hash[p] : 

if p3 is an integer or object cell 
return pShead mod TABLESIZS 
else if p3 is a string cell 

return sum[p3head] mod TABLESIZE 

where sum[s] returns the sum of 

the ASCII characters in the 
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string s 

else 

return 0 

endif 
end hash. 

This function is a crude hashing algorithm for string 
entries, with its primary virtue being simplicity. Object 
identifiers are generated linearly, however. The direct 
hash off these identifiers should result in minimal 
collisions. 

The structure itself consists of a pointer table (an 
array), with a collision list maintained for each entry. 
The collision list links together a collection of header 
cells. These cells have a key field with a list cell 

pointer, a definition field with another list cell pointer, 
and a link field with a pointer to the next header cell, 
figure 5.3 illustrates this structure. 

To complete the hash table description, a collection 
of management and access routines are used. These are; 

• Lookup. Given a pointer tc a cell, find an entry whose 
key field points to an equivalent structure. If found, 
return the definition pointer. 

• Install. Add an entry to the hash table. The hash 

table is searched for an existing entry with the same 
key value. If found, that entry is replaced. If not 
found, the new entry is linked into the appropriate 
collision list. Note that key entries may be any struc- 
ture: objects, strings, or lists. 

• Delete. Remove an entry from the table. The table is 
searched for the key value. If found, the entry is 
removed and its collision list is relinked if necessary. 
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Figure 5.3 Hash Table Structure. 

Object representatioLS are linked to object identi- 
fiers using these hash tables. The objects within Omega 
that have representations are relations, directories, rule 
denotations, and functions. These entities are subject to 
temporal change, and thus have an object implementation. 
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4 



. Hel ati ons 



Eelations are objects, but with a twist; they have 
access considerations. The access control mechanism is 
encoded directly into a relation’s object identifier. Three 
bits of the identifier signify whether the relation is 
accessible for read, add, or delete operations. When a new 
relation is created, an object identifier is generated and 
the capability bits all set tc 1, indicating full privi- 
leges. Subseguent operations may reduce the capability by 
copying the relation object identifier and zeroing the 
appropriate bits. This produces a second reference to the 
same relation, but with reduced access privileges. 

Relations are represented as lists, similar to the 
LISP prototype. As a tuple is added to a relation, a header 
cell is created for the tuple and linked in at the head of 
the existing tuple list (if any). A pointer to this list is 
bound to the relation’s object identifier through the object 
table. The list representation of a relation is shown in 
Figure 5.4 

5 • Dir ectorie s 



Directories incorporat 
general list structure. A dir 
a class link cell and a partiti 
The class link cell co 
tion cell, and a pointer to th 
class. A lookup path, then, 
directory to directory. 

The head pointer of the 
private partition, while the ta 
to the public partition. Each 
single hash table. 



6 the hash table into the 
ectory has two header cells; 
on cell. 

rtains a pointer to a parti- 
e next class link cell in the 
may follow this chain from 

partition cell points to the 
il pointer of the cell points 
partition is represented by a 
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Relation Headers 




Figure 5.4 List Bepresentation for Relations. 

In this implementation, directories are represented 
differently from relations. Ihis distinction was made to 
optimize directory access by hashing, although there is a 
loss of the generality enjoyed ty the LISP prototype. 

D. ORGANIZATION : THE TOP LEVEL 

The interpreter' s top level is similar to that of the 
LISP frototype. An added step — the print ph as e--r esu its 
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from the notion that a command rule "returns'* a result. The 
top level, then, consists of a read-evaluate-print-sweep 
loop- 

The r ead-evaluate-print phases process the user's 
command entry at the terminal. The print phase provides a 
visual indicator that some activity is taking place because 
of the command rule entry. 

Suppose a user enters the following rule at the 

terminal: 

if *E1 (z) -> R2 (X) , R3 (3) . 

The reader parses the expression, binds variables as appro- 
priate, and then passes the parse tree to an evaluation 
function. The response from the evaluation function is 

displayed at the terminal. In this example, this response 
would be "3." When multiple expressions exist in the 
consequent of a rule, the response from the last expression 
is displayed as the response for the rule. 

After the command rule has been evaluated and its 
response displayed, the interpreter begins its sweep phase, 
evaluating any active rules that are ready to fire. There 
is no implicit response from active rules: their purpose is 

to alter the database. At the completion of the sweep 
phase, the command loop returns to the reader and waits for 
the next entry. 

E. THE READER 

The reader was a major weakness in the LISP prototype. 
While an efficient parser implementation was not a major 
design goal for this work, the slow, error-prone parser of 
the LISP prototype was frustrating to work with. 

A parser generator was used to create the parser in the 
second prototype. This decision was made with the intent 



that a reasonably efficient parser be produced with a 
minimum of time and effort. 

1 . A 1^ Sc anne r 

The LEX lexical analyzer generator [Ref, 23] was 
used to produce the code for the scanner. LEX accepts as 
input a file of rules described through regular expressions 
and their associated actions. The output from LEX is a 
table-driven scanner in C source code. 

The following sequence defines LEX actions for 
recognizing unsigned integers: 

digit [0-9] 

int_con £digit}+ 

{int_con} £ 

return (INT_CON) ; 

} 

The return statement is an emtedded C language construct 
used to describe the required action by the scanner. In 
this example, INT_CCN is a constant used to represent the 
token . 

LEX is an easy-to-use, sophisticated tool. With no 
previous experience, we specified, generated, compiled, and 
debugged a LEX scanner in a few hours. The LEX specifica- 
tion for Omega is contained in Appendix A. 

2 • A Y ACC Pa rser 

The parser was written using the YACC (Yet Another 
Compiler-Compiler) parser generator [Ref. 24]. Like LEX, 
YACC allows a high level specification for compiler actions. 
The output from YACC is a table-driven, LALR(1) parser. The 
YACC parser receives its token input from the LEX scanner. 

The following illustrates the YACC specification for 
an Omega assertion: 
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assertion 



; primary '(' arguments ') ' 

{ 

$$ = newcell (ASSERT, $1, $3); 

} 

Additional rules are given for "primary" and "arguments." 
The newcell function generates a new cell with the tag 
ASSERT, a head pointer set to the value returned by YACC 
from parsing "primary," and the tail pointer set to the 
value returned by YACC from parsing "arguments." 

The embedded C expression determines the actions of 
the parser if an assertion is recognized. The assignment to 
"$$" defines YACC's response: this value is placed on a 

stack for use in other expressions. In this implementation, 
the value generated for each rule is a cell pointer. When a 
form is parsed success! ully, the YACC parser returns a 
pointer to the root of a parse tree constructed this way. 
The YACC specification for Omega is contained in Appendix A. 

YACC is a more complex tool than LEX, and it has 
some idiosyncra sies. These include precedence specification 
for infix expressions and a preference for left-recursive 
grammar rules. 

Infix expressions may be specified in YACC by a rule 

such as: 

expr : expr OP expr 

) 

Such a specification is ambiguous, however. To remove this 
ambiguity, YACC allows the declaration of precedence rules. 
Thus a precedence rule of: 

??left ’+• »-• 

%left V’ 

would establish the precedence of the arithmetic operators 
and resolve the ambiguities associated with the previous 



rule [Ref. 24; pp. 14-15]. This scheme results in a flat 
grammar for expressions in YACC, where the precedence rules 
determine associativity and precedence. 

Certain constructs in Omega lend themselves to 
recursive grammar rules. YACC encourages such rules to be 
left-recursive. Left-recursive rules result in a smaller 
parser size, and reduce the likelihood of an internal stack 
overflow when parsing a long sequence [Ref. 24: p. 19.]. 

Consider the following, left-recursive specification 
for a list; 

list : expression 

] list ' , ' expression 

The parse tree generated by such a rule is shown in Figure 
5.5 Cne consequence of this fcrm is that the entire list 
must be traversed to access the head of the list, an obvious 
disadvantage in list-oriented interpretation. 

To solve this problem while still respecting the 
YACC preference for left-recursion, a recursive transforma- 
tion is performed on parse trees. This transformation 
selectively changes left-recursive forms into right- 
recursive forms. The algorithm is: 

rtrans[curr, pred] : 
if curr = Nil 

return Nil 

else if curr points tc an atom 
return curr 

else if curr is not a left recursive form 
currShead ;= rtrans" currShead, Nil ] 
currStail := rtrans[ currStail, Nil ] 
return curr 

else 

h := rtrans[ curr ahead, curr] 
t := rtrans[ curratai 1, Nil] 
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currSiead := t; 
currStail ;= pred 
if h = Nil 

return curr 

else 

return h 
end if 
end if 
end rtrans 

Figure 5.6 shows the list after the transformation has been 
applied. 

The YACC parser offers several advantages to a 
prototyping effort: 

• Development time. The high level of the specification 
for YACC minimizes the complexity of parser generation. 
Fe had a complete, functional parser working in three 
days . 

• Ease of modification. Experimentation with syntax is 

simple: change the grammar rules, rerun YACC, and 

recompile the output. The ease with which the grammar 

can be modified encourages experimentation. 

• Verifying specifications. Analysis of grammar changes 
is easy in YACC. If a change produces ambiguities, YACC 
will report conflicts when trying to generate the parser 
tables. This automated analysis is a strong point in 
favor of using a YACC parser. 

3. Co nsole and File Input 

As in the LISP prototype, the same parser is used to 

read command rules from the console and from text files. 

This is implemented using the i/o redirection facilities of 
DNIX and C. 
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List: [1, 2, 3] 







Figure 5.5 Left-Recursi ve List Representation. 

The scanner produced h}' LEX accepts input fro 
standard input file by default. To receive input 
another text file, the file is opened and the LEX input 
variable reassigned. This simple techni>iue allows 
alternation of input between several sources. 
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1 



List; [1, 2, 3] 




Figure 5.6 Transforied List Structure. 

F. A EECORSIVE PRETTY PRINTER 

The parser, along with the cell allocation routines to 
generate the parse tree, was the first system component 
developed for this implementation. A pretty printer was 
written at this point primarily to debug the parser. 

The pretty printer is based on a large case statement, 
which selects the appropriate output form based on the tag 
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of the current subtree. A section of the al'jorithm may be 
described as: 

pretty_print[ p ] : 
do case pStag 

case RULE ; 

print[ "if" ] 
pretty_print[ pShead ] 
print [ "->» ] 
prett y_print[ pStail ] 
print [ ] 

• • • 

end case 
end pretty_print 

Although the pretty printer originated as a debugging 
aid, the basic design of the tag-oriented case statement was 
almost identical for the central evaluation function. This 
pretty printer evolved into the Display mechanism for the 
interpreter. 

G. ROLE EVALDATIOH 

Where the LISP prototype used a separate, iterative 
execution function for backtracking, the follow-on design 
uses a recursive backtracking algorithm within a single 
evaluation function. 

As in the pretty printer, the heart of the evaluation 
function is a large case statement. The tag value of the 
form being evaluated determines the case selection. A 
section of this case statement may be described as: 

eval[ip, ep ] : 

do case ip2tag 

case RULE: 
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result := rule[ i p3head, ipStail^ ep] 



end case 
return result 
end eval 

As in the LISP prototype, separate functions are defined for 
the majority of interpreter actions. The function rule is 
defined external to the case statement, and contains code 
for the interpretation of the RULE operator. Separate calls 
to eval are used to evaluate the arguments to rule. 

The evaluation function receives two arguments: a 

pointer to the subtree being evaluated (ip) , and a pointer 
to the current directory for global name definitions (ep) . 
The evaluation function returns a cell pointer as its 
result. 

H. BINDING 

I • k%. A ctivati on 

This implementation uses an entirely different 
binding mechanism than the LISP prototype. The variables of 
a rule denotation are bound when a rule becomes active. 
These bindings are determined by the environment of activa- 
tion. Since a command rule is immediately executed, binding 
takes place immediately for these rules. 

The binding process results in a complete copy of 
the parse tree for a rule, leaving the original denotation 
unaltered for later use. In this way, the denotation is 
like a source file, the bound parse tree like an object 
file . 

When a rule denotation is bound, the current direc- 
tory is searched for variable definitions. The class of the 
current directory provides a search path to other directo- 
ries if the variable is not bound in the current directory. 
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A variable not defined in the directories of the 
class is a free variable. The cell representing a free 
variable contains an offset in the head field, and a pointer 
to the variable's print name (a string cell) in the tail 
field. The offset for a variable depends on the order in 

which the free variables of a rule appear. 

When a free variable cell is initialized, a pointer 
to the variable cell is installed as the print name's defi- 
nition in a local symbol table. Subsequent occurrences of 
the variable will be replaced by this definition. 

During the binding process, the parse trees for 
embedded rule denotations are installed in the object table. 
A system-generated object identifier replaces the rule deno- 
tation subtrees in their parent expressions. The variables 
in the rule denotation are left unbound — the binding of 
these variables is deferred until the denotation is 
activat ed. 

The final action for the binding process is the 
creation of an allocation operator cell for the rule. This 
cell has a count of the total number of free variables for 
the rule in its head field. The tail field contains a 
pointer to the actual rule structure. 

2 - A B ind i ng St ack 

The allocation operator is used with a binding 
stack. The binding stack is an array with a current frame 
pointer and a chain of dynamic link pointers that connect 
frames. The binding stack is illustrated in Figure 5.7 

When a rule begins interpretation, a stack frame is 
created on the binding stack with slots allocated for each 
free variable in the rule. The offset in a variable cell 
indicates which of the binding frame slots is to be used for 
that variable. 
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Figure 5.7 The Binding Stack. 
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The binding process uses the following primitive 
routines : 

• bind[X/ y ]. The frame slot for variable x is assigned 
pointer y. 

• getbinding[ X ]. Return the value in the frame slot for 
variable x. 

• freebinding[ X ]. Free the binding for variable x. This 
is accomplished by assigning a reserved value to the 
frame slot meaning UNBOUND. 

When a rule completes execution, the dynamic link is 
followed to the previous frame, and the current frame 
pointer reset. 

The binding stack offers several advantages. First, 
variable lookups are only done once: at activation time. 

The dynamic binding process is only concerned with a vari- 
able's offset in the stack frame, not with the variable 
name. The binding stack allows the simple reclamation of 
storage used for binding. Finally, it allows context 

switching in rule interpretation since bindings from inter- 
rupted rules are preserved. 

A context switch for a rule occurs during a synchro- 
nous call. Consider the following rule: 

if *R1 (X) -> { F.2{x}; R3 {x} }. 

When the E2 procedure call is made, a context switch is made 
to the body of rules that support the call. The binding of 
the variable x, however, must be maintained between the R2 
procedure call and the R3 procedure call. 

This method of static binding eliminates unnecessary 
variable lookups by replacing variables by their defini- 
tions. Generality is still maintained for objects such as 
relations, whose associated values are determined by dynamic 
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lookups in the object table where necessary. Thus, the 
philosophical differences between objects and values in 
Omega are supported by concrete differences at the implemen- 
tation level. 

I. BACKTRACKING 

A recursive backtracking algorithm is implemented with the 
conditions (CONDS) operator. A condition is an element of 
the antecedent of a rule; a presence/ inquiry test, an 
absence test, or a constraint. Backtracking is initiated 
only on the failure of a presence test. The algorithm is: 

conds[ cond_curr , cond_next, ep ] ; 
match_next_ptr := Nil 
while TRUE 

result := eval[ cond_curr, ep ] 
if result = FAIL 
return FAIL 

else if cond_next = Nil 
return result 
end if 

result := eval[ ccnd_next , ep ] 
if result != FAIL 
return result 

endif 

if cond_curr is not a ’present* op 
return FAIL 
end if 

undo trial bindings made for condition 
end while 
end conds 

This algorithm treats backtracking as a binary operation. 
The ”cond_curr" parameter is the current condition being 
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tested. The "cond_next" points to the remaining list of 
conditions to be tested. A successful response from eval on 
"cond_next" indicates that all remaining conditions have 
tested successfully. A failure means a backtrack attempt 
should be made on the current condition. 

J. RELATION MANAGEMENT RO0TIHES 

The relation management routines of the LISP prototype 
are continued in this implementation. They are; match, 
add, and delete. As in the LISP prototype, the add function 
links a new tuple at the beginning of the relation list. 
The delete function removes the tuple from the relation list 
and relinks as necessary. 

A pattern-matching algorithm is used in the relation 
match function. As in the LISP prototype, the tuple list of 
a relation is searched linearly. As each tuple is selected 
for a match, it is passed to the pattern-matching function. 
The match function maintains a "match_next" pointer. This 
indicates where the last match occurred, and provides a 
search continuation point for backtracking. 

The pattern-matching algorithm is similar to that given 
in Chapter III. Unlike in the LISP prototype, trial vari- 
able binding occurs during pattern matching. The pattern- 
matching function binds free variables by using the bind 
operator of the binding stack. These bindings are undone if 
a rematch is necessary when backtracking. 

In this implementation, relation access control is 
enforced. The object identifier for the relation is first 
tested to ensure the capability bit for the desired opera- 
tion is set. If not, the operation is canceled and an error 
message is generated. 

An additional relation function was added: match_first. 
This function returns a pointer to the first tuple in a 
relation. 
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K. ACTIVE RULE PROCESSING 



1 . Triggers 

The technique of triggering is used to improve the 
precision of active rule processing. The trigger for a rule 
is the left- most relation in the the rule. For the 
following rule: 

if *R1 (X) , *R2 (y) -> . . . 

the trigger is the relation B1. 

A rule is selected for test when certain events take 
place involving the trigger relation. These events are 
assertions and deletions. If either of these operations is 
performed on the trigger relation, there is a likelihood 
that the rule's antecedent conditions are now satisfied. 

The triggering process is initiated at the time a 
rule is activated. The trigger for a rule is determined, 
and the rule installed in an active rule table (a hash 
table) , keyed by the object identifier for the trigger rela- 
tion. A list is maintained in the active rule table for all 
rules associated with a given trigger. 

When an assertion or denial is made to a relation, 
any rules indexed by that relation are selected from the 
active rule table and tested. 

A rule is always tested at least once: when it is 
activated. This ensures that any pending conditions will be 
serviced before the rule enters its triggering cycle. 

2. A Ru^ Qu eue 

Triggered rules are managed through a circular 
queue. When a rule is triggered, a pointer to the rule is 
placed in the rule queue. 

During the sweep phase, all rules in this queue are 
tested. If a rule succeeds, it remains in execution by 
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staying in the rule queue. Instead of undergoing continuous 
evaluation, a successful rule is reinserted at the end of 
the queue. This enforces a fairness policy: each rule in 

the queue should get a turn at evaluation. 

Given the nature of rule testing, only one instance 
of a rule needs to be in the queue at one time. Multiple 
instances will result in wasted interpreter cycles and 
excessive queue sizes. 

To control this problem, a flag bit is used. The 
flag bit is contained in the tag field (bit 7) of the first 
cell in an active rule list. '.Ihen a rule list is placed in 
the queue, the flag bit is set. Subsequent attempts to 
insert the rule list in the queue will be ignored because of 
the flag bit value. When the rule list leaves the queue (by 
being selected for testing) , the flag bit is reset and 
subsequent queue requests for the rule will be accepted. 

3. Advant a ges and D isa dvan taqes of Trig ger i ng 

Rule triggering has the following advantages: 

• Precision. The likelihood of triggered rules firing is 
good. The strategy is much more precise than the global 
sweep strategy of the LISP prototype. 

• Simplicity. The triggering mechanism described is 

simple, both in concept and in its supporting 

i iplementation. 

• Triggers are statically determined. The trigger is the 

left-most relation of a rule. This is a simple, 

syntactic distinction that is directly inferable from 
the visual form of a rule. 

Despite its attractive aspects, the trigger mecha- 
nism just described is too simple. To illustrate this 
point, consider the following rule: 
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if El (X) , -'E2 (X) -> B2 (x) . 



The intent of this rule is to enforce the constraint that El 
should remain a subset of E2. 

Assume El and H2 initially contain the same tuples. 
If a tuple is removed from E2/ the relation contents are 
different and the constraint rule should fire. Given the 
previous triggering strategy, however, the rule will not be 
tested. The affected relation was B2, but the rule is trig- 
gered on El. 

4. Two-Le v el Tr iggerin g 

A possible alternative to this simple triggering 
method is to index a rule on every relation in the antece- 
dent. This will guarantee a correct evaluation, but 
requires a complex index structure. Also, triggering on 
secondary relations is inefficient — these relations may be 
updated frequently and result in excessive testing for the 
rule. 

Another possible alternative is to determine the 
point of failure. In the following rule: 

if ♦El (X) , *B2 (y) -> . . . 

the El inquiry may succeed and the B2 inquiry fail. If the 
E2 relation is flagged as the point of failure for this 
rule, a subsequent assertion tc E2 could be the trigger for 
a retest of the rule. 

The difficulty with this strategy is determining the 
point of failure. Consider the following rule: 

if *E1(X), *E2(x, y) , *E3 (x, z) , x > y -> . . . 

Each of the relations El, H2, and b 3 may have a tuple that 
meets the pattern specification. There is a dependency, 
however, among these inquiries and the constraint. A 
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failure, then, may be a failure of the combination and not 
of any particular inguiry. 

A compromise strategy is used to solve this problem. 
We call this technique two-level triggering. 

Using two-level triggering, two rule queues are 
maintained. One is for active, triggered rules selected 
under the original triggering strategy. This is the primary 
rule queue. The second queue contains rules pending altera- 
tion of one or more conditions to enable firing. This is 
the secondary rule queue. 

When a rule is initially triggered, it is inserted 
in the primary rule queue. If, when tested, none of the 
conditions of its antecedent successfully match, the rule is 
discarded. 

If, on the other hand, at least the trigger condi- 
tion successfully matches {but the combination fails) , the 
rule is entered into the secondary queue. The rules of the 
secondary queue are tested after the rules of the primary 
queue have been expended. 

Once inserted into the secondary queue, rules will 
remain under evaluation for possible firing. A rule will 
leave the secondary queue under two conditions: 

• The rule fires and is transferred back to the primary 
q ueue. 

• The rule fails to match on its trigger relation and 
leaves the active queues completely. 

Two-level triggering may be inefficient. Consider 
the following rule: 

if *Employee_Da ta (name, salary), salary > 10000 -> 
Employee_Data (name, salary/2). 
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lf the Employee_Data relation is normally not empty, 
level triggering will perpetually maintain this rule in 
either the primary or secondary rule queues. If many rules 
behave this way, the rule selection strategy degrades to a 
global sweep, a worst-case performance. 

Many types of rules fair well under two-level trig- 
gering. The key to efficiency for this strategy lies in 
the use of the trigger relation. This relation should 
contain matching tuples only when the rule is ready to fire. 

1. THE APPLICATIVE COHPONENT 

The original description cf Omega did not contain a 
detailed description of the applicative component. Instead, 
it assumed that a completely separate applicative language, 
such as MacLennan* s A [Ref. 25], would be integrated into 
the Omega environment to support applicative evaluation. 

The applicative component was a minor issue in the LISP 
prototype, but the fcllow-on design had to resolve its role 
and form. Some of the alternatives considered were: 

• Develop a general applicative interpreter interface. 
The Omega interpreter and applicative interpreters would 
be separate processes communicating through this 
interface. 

• Integrate the code for an existing applicative 
interpreter into the Omega structure. 

• Use simple modifications to Omega grammar and semantics 
to add an applicative component to the language. 

The first option offers the potential for multiple eval- 
uation functions. In one environment, an applicative 
expression may be evaluated by LISP. Another environment 
may use an A interpreter. 
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This option was discarded for efficiency reasons. 
Applicative expressions use pointers to Omega structures, 
which implies shared memory access. Separate processes 
would have to pass this information through an i/o opera- 
tion, such as a mailbox transfer or a UNIX socket [Bef. 26]. 

The second option was discarded because of complexity, 
and rhe third selected for the same reason. Minor modifica- 
tions to Omega itself allowed the rapid development of a 
simple but useful applicative mechanism. 

The only completely new language feature needed was the 
function definition, which has been shown in previous exam- 
ples. A function definition takes effect at the same time 
rule variables are bound. 

The function definition performs the following actions: 

• The function name is bound to a system-generated object 
identifier and installed in the current directory. 

• The function is separated into a pair, <fp, b>, with 
formal parameters (fp) and a function body (b) . 

• The formal parameters are installed as free variables in 
the local symbol table. The variables of the body are 
then bound. These variables will contain the stack 
frame offsets of their corresponding formal parameters. 

• An allocation operator is linked to the <fp, b> pair. 
This operator is used to create space on the binding 
stack for formal parameter binding. 

• The function structure is installed in the object table, 
keyed on the object identifier. 

The function definition is different from the other 
features of Omega. The mechanism bypasses the "Define" 
procedure to allow recursive definitions. Note that the 
installation of the function name and object identifier into 
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the current directory is done first. When the variables of 
the function body go through the binding process, recursive 
references to the function name will be handled properly. 

When a function call is evaluated, the function struc- 
ture is retrieved from the object table. The allocation 
operator is interpreted, and a frame created on the binding 
stack for the function's parameters. 

The actual parameters for the function call, previously 
evaluated, are grouped together in a list. This list is 
traversed, and the pointer for each actual parameter is 
assigned to a slot in the current binding stack frame. At 
the completion of this process, all formal parameters are 
bound . 

The function body is then passed to the central evalua- 
tion function. At this point, the function body is simply 
another rule, and it is processed by the rule evaluation 
routines. The binding stack supports recursion in function 
evaluation. 

This applicative mechanism has the advantages of 
simplicity and uniformity with the Omega syntax. The func- 
tion definition, however, does not conform well with the 
other constructs of the language. Also, lambda expressions 
and functionals — key components of an applicative language-- 
are not implemented. 

Despite its limitations, a variety of interpreter 
utility functions were defined using this mechanism. These 
functions are listed in Appendix C. 

M. PEOCEDUBES 

With the evaluation and binding mechanisms already 
introduced, the implementation of a procedure call mechanism 
is simple. The steps for procedure call evaluation are: 
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• Evaluate the tuple participating in the procedure call. 
This tuple is analogous to the actual parameters of a 
function call/ and is impleitented as a linked list. 

• Generate a new relation object for the mailbox. This 
object is linked at the beginning of the tuple list. 

• Assert the tuple into its target relation. The asser- 
tion mechanism will gueue any rules triggered as a 
result. 

• Execute the sweep function to evaluate any triggered 
active rules. The sweep function will continue to 
execute if there are rules to fire. 

• Apply the match_first operation on the mailbox relation 
to extract the response from the call. It is this 
response that is returned as the result of the procedure 
call. 

While the procedure call gives a measure of control to 
rule processing, the mechanism is still unstructured. The 
philosophy of this implementation is "make the assertion and 
see what happens." One possible consequence of the mecha- 
nism is multiple assertions to the mailbox. 

Consider the following active rule; 

if *R (a) -> a ("Yes"), a ("Nc") . 

If triggered as a result of a procedure call, what is the 

value returned by the call? The use of the match_first 
operation and the LIFO implementation of relations will 
return the last assertion as the response. Other assertions 
are ignored. While this convention seems tractable, it is 
implementation- depen dent. 
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N. BOILT-IN FUNCTIONS AND PEOCEDOBES 



While implementing the interpreter, the necessity for 
"hard-wired" functions and procedures became apparent. By 
hard-wired, we mean that these mechanisms are supported by C 
functions coded in the interpreter, as opposed to an imple- 
mentation in Omega rules or functions. These mechanisms are 
built-in for purposes of efficiency. An example is the 
Define procedure call. 

In the ilS? prototype, directories were implemented as 
relations and the Define mechanism was implemented with 
Omega rules. By using different representations for direc- 
tories and relations, the Define mechanism has a different 
character that reguires a more specific implementation. 

Names like "Define" are implemented as system objects. 
Eecall that a block of object identifiers is reserved for 
system use. When a relation identifier is evaluated, system 
objects are processed by a different set of routines: one 
for system-defined relations and one for system-defined 
functions. 

The object identifiers for these relations and functions 
are examined in a case statement, and the appropriate system 
routine called. The routine for Define receives the parame- 
ters (pointers) for the target directory, the name, and the 
definition. The entry is then installed in the hash table 
for the directory. 

The steps required to add a system-defined function are 
simple: 

• An entry is made in the object header file. This file 
contains the definitions of reserved object identifiers. 

• An entry is made in the case statement for the system 
relation or function handler. 
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• A directory entry is predefined in the system initiali- 
zation routine. This routine builds the system’s root 

directory. 

This mechanism allows the access of system routines from 
Omega rules. The procedures for NewBel and NewObj are 
implemented in this way. Similarly implemented is the 
Display procedure call, which passes a structure pointer to 
the system pretty printer. 

This system interface replaces the ubiquitous function 
definitions of the LISP prototype. The process required to 
implement a feature as a function call or procedure call is 
the same; the mechanism may be selected that most appropri- 
ately models the desired activity. Appendix B lists the 
built-in functions and procedures for the system. 

0. CANCEL OPERATIONS 

The implementation of cancel operations relies on two 
features of the interpreter: the "iaatch_next" pointer into 
a relation, and the binary backtracking algorithm. 

In the backtracking algorithm, a successful evaluation 
of the "next_condi tion” pointer indicates that the remaining 
conditions of the antecedent have all been successfully 
evaluated. at this point in the recursion, a pointer to the 
match position in the current relation is available if back- 
tracking is required. If the current operation is a cancel, 
the " match_next’' pointer references the tuple that should be 
deleted. This deletion is done directly by marking the tag 
field of the tuple. 

The tuple is not removed directly from the relation 
because a pointer to the tuple's predecessor in the relation 
list is not available. The alternative to marking is to 
search the relation from the beginning, maintaining a pred- 
ecessor pointer, until the canceled tuple is found. The 
relation could then be properly relinked. 
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Marking was used to avoid excessive searching of rela- 
tions. When a relation is scanned on subsequent inquiries, 
the tuples marked for deletion are removed. In this way, 
the overhead of linear search is minimized. 

MacLennan introduced the cancel operator as a notational 
convenience [Bef. 14: p. 18]- This simple construct demon- 
strates several desirable qualities of a language feature: 

• The notation is compact, yet readable. The cancel oper- 
ation removes the necessity to code a redundant delete 
operation. This saves space in the source file and in 
the resulting parse tree. 

• A potential source of error is removed. The relation 
name and tuple pattern of delete operations normally 
correspond exactly to their counterparts in a presence 
test. It is easy to misspell identifier names in the 
delete clause. 

• Cancel operations allow optimization. The use of the 
•' match_next" pointer reduces search time. When a delete 
operation is evaluated, there is no easy way to link 
this to searches conducted when processing the rule's 
antecedent . 



P. SEQUENTIAL BLOCKS 

The implementation of the sequential block involves two 
functional character istics: (1) the sequential evaluation 
of rules within the block, and (2) the nested scoping of 
free variables. 

Sequential evaluation is a natural consequence of the 
interpreter's design. The implementation evaluates the 
actions of a rule's consequent in a lef t-to-righ t sequential 
order. The rules within a sequential block are processed in 
the same way. 
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■ 1 . A S inq le-Pass/ Multi-Sccpe Symbol Tabl e 

The nested scopes of sequential blocks require an elabora- 
tion of the binding process previously described. Scoping 
is handled by the following steps: 

• A block count is maintained during binding. As a 
sequential block is entered, this count is incremented. 
When the binding of the block is complete, the block 
count is decremented. 

• Variables have a block number and an offset. As new 

free variables are encountered in a sequential block, 

their offset is determined. The variable index, 

contained in its head field, now contains two elements: 
a block number and an offset within the block. 

Free variables are installed in a local symbol table 
as they are encountered in the binding process- To 

correctly process references to outer blocks, a multi-scope 
symbol table is required. This symbol table is implemented 
as a two stack structure: one stack maintains the variable 

reference pointers, the other stack maintains scope 
pointers. As each variable is encountered, the symbol table 
stack is searched from the current stack top to the base. 
If found, the variable is replaced by the definition 
returned. New variables are installed in the symbol table 
by pushing the variable reference on the stack. 

As a sequential block is entered, the stack top for 
the preceding scope is saved on the scope stack. When the 
binding of the sequential block is complete, the predeces- 
sor’s stack top is restored from the scope stack. The scope 
stack partitions the variable reference stack into the 
appropriate scopes. The structure is illustrated in Figure 
5.8. This symbol table structure is similar to structures 
used fcr conventional,- block-structured languages [Ref. 27: 
pp. 325-327]. 
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Figure 5.8 Multi-Scope Symbol Table. 
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2 . 



Bva lu a tion of Multi - Sc o pe Bindings 

The dynamic evaluation of bindings requires modification to 
process the nested scopes of seguential blocks. The evalua- 
tion function has the following additional features: 

• A global scope count- This is incremented when a 
sequential block begins execution, and decremented when 
the seguential block is completed. 

• Walking the links. The getbinding operation for the 
binding stack must now take scoping into account. To do 
this, the block number of the variable is compared to 
the interpreter’s global scope number. If these numbers 
are not the same, then the correct stack frame is 
located by traversing n links up the binding stack, 
where n = variable block nunber - current scope number. 

• Function and procedure context switches. Functions and 
procedures require new scopes- This is accomplished by 
the following sequence: 

Scope_Save := current_Sccpe 
current_Scope := 0 
Execute the procedure or function 
current_Scope ;= Scope_Save 

This process is similar to static link processing in conven- 
tional block-structured languages, such as described in 
[Ref. 19: p. 232-238]. 

This implementation does not require separate static 
and dynamic links. Procedures and functions execute in 
scopes separate from their points of invocation. A single 
set of links in the binding stack is sufficient to support 
multi-scope references and the calling chain of functions 
and procedures. 
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Q. SYSTEH INITIALIZATIOH 

The system initialization sequence is similar to that of 
the LISP prototype. The root directory is initialized with 
the names of the systems’s built-in functions and proce- 
dures. As in the LISP prototype/ the directory has a self- 
referencing entry. 

An Omega initialization file is parsed and evaluated. A 
call to the sweep procedure propagates any rule activity 
resulting from these rules. This initialization provides 
the definitions for utility functions and procedures. These 
utility rules are listed in Appendix C. 

To augment the initialization file, the user may specify 
an Omega file name on the UNIX command line. The inter- 
preter will parse and evaluate these rules as part of the 
initialization process. 

Finally, the interpreter enters the read phase of its 
read-evaluate- print- sweep cycle. 
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VI- STORA^ MNAGEMENT 



A. TBE STORAGE PROBLEM 

The tasic storage unit for Omega is the cell. These 
units are allocated dynamically, to support changing list 
structures, temporary results from computations, and 
changing relation contents. Dynamic memory allocation and 
dynamic typing make relation manipulation a flexible but 
complex activity. 

The task of freeing unneeded storage quickly became too 
complex for explicit memory reclamation in the interpreter 
design. By explicit memory reclamation, we mean that, at a 
certain section of the code, it can be determined that a 
cell is no longer needed and a call to a reclamation routine 
can be immediately made. 

Reclamation is complicated by memory sharing. This 
sharing is a natural consequence of the design of Omega, and 
comes from pattern-matching and reuse of active rule 
structures. 

Consider the following rule: 
if R1(x), -.R2(x) -> R2 (X) . 

When tuples are asserted to the relation R2, two possible 
strategies may be used: 

• Copy the structure. The complete tuple structure is 
copied, and the ccpy added to the R2 relation. 

• Share the structure. The match operation returns a 
pointer to the tuple in R1. It is this pointer that is 
bound to the variable x, and available for inclusion in 
R2. If the structure is net copied, the pointer added 
to E2 refers to the same structure as that in R1- 
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Consider another rule; 



if *R1 (1) -> R2 ([1, 2, 3]) . 

The assertion to H2 adds a tuple generated by a list denota- 
tion in the rule — this denotation is linked into the rule 
structure. As in the previous example, the assertion mecha- 
nism may choose to copy the structure or share the 
structure. 

Structure sharing is preferable for two reasons: space 

and time. Structure sharing obviously reduces storage 
requirements by allowing multiple references to the same 
storage areas. Of more importance in this implementation is 
a reduction in execution time. The tuples of a relation may 
be arbitrarily complex list structures. Copying these 
structures continually is an execution overhead that struc- 
ture sharing avoids. 

B. STORAGE ALLOCATION AND THE DNIX VIRTUAL ADDRESS SPACE 

The implementation uses the storage allocator provided 
in the UNIX C library. The allocation routine is malloc. 
The reclamation routine is free. [Ref. 26] 

To understand how these routines work, a description of 
the UNIX virtual memory map is useful. An executing process 
has its virtual memory divided into three logical areas: a 

text segment, a data segment, and a stack segment [Ref. 26]. 

The text segment contains the program code. This 
segment is normally shared and re-entrant. The stack 
segment is used for the system's runtime stack. The stack 
begins at the highest possible virtual address, and grows 
down. The stack area is automatically extended as required. 

The data segment consists of two sections: initialized 

and uninitialized storage. The initialized storage area 
contains statically allocated storage declared in the 
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program. In this implement alien, the binding stack, symbol 
table stack, and rule queues are implemented as arrays. 
Their storage allocation appears in the initialized storage 
area . 

The uninitialized storage area is used for dynamic 
memory allocation. Calls to aalloc will extend this area. 
Calls to free will reclaim, compact, and free virtual 
storage where possible. 

The maximum sizes for the stack and data segments are 
system-dependent and locally tailored to achieve desired 
performance goals. The system used for this work has the 
following limits set: 

data segment — 6112 kbytes 
stack segment — 512 kbytes 

This organization is illustrated in Figure 6.1 

Halloc allocates memory aligned on word boundaries. 
Structure storage requirements are rounded to the next four 
byte multiple based on the 32 bit word size of the VAX. The 
consequence of word alignment is an additional space 
requirement for cells. Even though the design only speci- 
fies 8 bits for the tag field, this requirement is rounded 
to 32 bits. A cell has 12 bytes allocated, with 3 bytes of 
storage (25 percent) unused. 

C. IGMOBING STORAGE MANAGEMENT 

The interpreter was initially implemented with no 
storage management strategy. Cells were allocated when 
necessary, but no attempt was made to free excess storage. 

This policy proved to be unsatisfactory. A lengthy test 
program exceeds the system data segment limits. On one 
test, the interpreter ran for 10 minutes before exhausting 
its available memory. At this point, 384,159 cells had been 
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allocated using 4,5 Mbytes ot virtual memory for cell 
storage. 

It is possible, but not necessarily desirable, to 
increase the data segment limits for a process. The data 
segment limit used during testing--6 Mbytes — should be more 
than sufficient for this implementation. A large, 

constantly growing process also suffers from excessive swap 
space reguirements and a high page fault rate. 

These factors point out a familiar lesson; while virtual 
storage systems allow a large address space, storage manage- 
ment is still a major consideration. These policies are 
particularly important in a multiuser operating system such 
as UNIX, where excessively large processes can have an 
adverse impact on the user community. 

D. OHEGA-SPECIFIC STORAGE OPTIMIZATION 

Approaches were considered which reduce the storage 
reguirements of the system by focusing on specific charac- 
teristics of the implementation. Two areas for optimization 
were: (1) eliminate expression evaluation during pattern- 

matching, and (2) reclaim cell storage for the initial 
tuples added to relations. 

The pattern-matching routines are executed freguently as 
rules are selected for test. An active rule structure is 
reused, so intermediate results must have separate storage 
allocated. Consider the following rule; 

if *IsManager {a , x) , Posit ion ("Manager : " + x) -> 
a ("is Manager") 
else if *IsMana ger (a, x) -> 

a ("is not Manager") . 

In the Position inguiry, the "+" represents string concat- 
enation. To evaluate this rule, a new tuple must be 
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generated to record the results of the concatenation opera- 
tion. This tuple is then used in the inquiry. Cells such 
as these laay be generated frequently during rule testing. 

A possible optimization to this requirement is to 
restrict expressions in the antecedent of a rule to 
constraints. Strict pattern-matching is supported primarily 
by the binding stack and little additional memory is 
required. If expressions are limited to constraints, and 
constraints shifted to the end of a list of antecedent 
conditions, rule failures will occur before the constraint 
is evaluated, minimizing dynamic memory allocation. Tests 
conducted using this strategy showed a decrease of cell 
allocation ranging from 10 percent to 40 percent. 

While this strategy reduces memory requirements, the 

basic issue of storage reclamation is not solved. The 

restriction on tuple expressions is significant — the 

programmer must now remember this as an exception to syntax 
and semantics. 

One possible alternative tc the above strategy is the 
use of a separate storage allocator and reclamation routine 
for intermediate, temporary storage. This approach was not 
pursued because a more general solution to the storage 
management problem was needed. 

Certain types of relations tend to be small, with a 
cardinality of 1 or 0. Consider the following rule; 

if *?ush(a, X, 1) -> 
a (£ X : 1 ]) . 

This rule executes a Push operation by cons'ing the member x 
onto the list 1. 

While multiple agents may have requests to Push active 
at the same time, a typical situation is where Push contains 
a single request which is serviced and promptly removed. A 
simple strategy optimizes storage for such relations. 
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A relation list has a collection of cells which we refer 
to as tuple headers (illustrated in Figure 5.4). These 
headers link pointers into the relation list which refer to 
the actual structures of the tuple members. While the 
pointers nay change, the number of header cells is dependent 
on the tuple cardinality. This cardinality tends to remain 
fixed after it is dynamically determined. 

When the first tuple is added to a relation, the header 
cell requirements are allocated. A cancel will flag this 
tuple as deleted by marking the tag, but the tuple will 
remain linked into the relation list. A subsequent asser- 
tion may then reuse these header cells for the next tuple. 

This strategy allows a simple optimization of relation 
storage requirements. Early tests of this strategy indicate 
a potential 10 percent reduction in cell allocation. The 
strategy postpones memory exhaustion but doesn't prevent it; 
a more general storage management policy is still required. 

E. EEFERENCE COUNTING 

Reference counting was selected for cell reclamation. 
This technique is described extensively in the literature. 
Our algorithms are based on the material presented in 
[Ref. 19; pp. 440-442] and [Ref. 28: pp. 383-384]. 

The implementation of reference counting required the addi- 
tion of a reference count field in the cell structure and 
some simple management routines. 

Since 25 percent of cell storage is wasted, the inclu- 
sion of a reference count field bears no additional cost. 
The reference count field is implemented as a 1 6 bit signed 
integer, although a smaller field would be sufficient. 
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The reference counting routines are as follows: 

• IncrEef — Increment a cell reference count: 

IncrEef^p] : 

if p = Nil 

ret urn; 

else 

pSrefcount := fSrefcount + 1 

endif 

end. 



• DecrEef — Decrement a cell reference count: 

DecrEef [ p ] : 

if p = Nil 

return ; 

pSrefcount := pSrefcount - 1 
if pSrefcount <= 0 

if p3 is a string cell 

free string storage 
else if pS is a list cell 
DecrRef[ pahead ] 

DecrRef[ p2tail ] 

endif 
free p 

endif 

end DecrRef 



When a cell for an atom is created, its reference count 
is initialized to zero. Reference counts are altered when 
pointer references change. This occurs in the following 
routines; 
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• NewCell — Create a new list cell. The algorithm is: 

KewCell[x, y]: 

p := malloc[ cells! ze] 
pSrefcount := 0 
p3>head : = x 
po)tail := y 
IncrRef [ x ] 

Incr Ref [ y ] 
return p 
end NewCell 



• SetHead — Change the head pointer for a cell. This is 
the rplaca function of LISP; 

SetHead[x, y]: 

IncrRef[ y]; 

DecrRef[ xShead]; 
xShead := y 
end SetHead 



• SetTail — Change the tail pointer for a cell. This the 
rplacd function of LISP: 

SetTail[x, y]: 

IncrRef [ y ] 

DecrRef[ xoitail] 
xStail := y 
end SetTail 



Reference counts also need to reflect the references of 
a recursive implementation. To illustrate this point, 

consider the following interpreter routine to implement 
multiplication: 
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Mult[X/ y] : 

IncrRef[ x ] 

IncrRef[ y ] 

temp ;= MaJcInt[ xShead * yShead] 

DecrRef[ x ] 

DecrRef£ y ] 
return temp 
end Mult. 

Before its invocation, the arguments to Malt have been 
recursively evaluated. If these parameters involved expres- 
sions, then either parameter may be an intermediate result. 
The IncrRef operations reflect the Mult routine’s references 
via its formal parameters. After completion of the multipli- 
cation, the references are decremented with DecrRef, which 
will free intermediate results that are no longer required. 

Reference counts must remain consistent, so an analysis 
of local references throughout the interpreter was required. 
A point of interest is the binding stack: the bind operation 
must increment a cell's reference count while the unbind 
operation must decrement the reference count. The determi- 
nation of these specific reference counting points proved to 
be a tedious process, although still more tractable than 
explicit reclamation. 

Reference counting offers the following advantages; 

• Simplicity. The data structures and algorithms are 
supported by the existing recursive interpreter design. 

• Immediate reclamation. Unneeded storage is reclaimed 
i mmediately. 

• Uniform computational requirements. The overhead of 
storage reclamation is spread out over the execution 
time of the interpreter. 



107 



A major limitation of reference counting is the diffi- 
culty in reclaiming cyclic structures. The design of Omega 
prevents this problem- Only "pure" lists are used and 
rplacz operations are not defined. 

Reference counting places a computational fcurden-- 
incrementing reference counts--at a sensitive point: memory 

allocation. The execution penalties associated with refer- 
ence counting are examined in the next chapter. 

P. GARBAGE COLLECTION 

Garbage collection was not eelected as a storage manage- 
ment strategy because of the complexity of implementation. 
The malloc and free routines offer a predefined storage 
allocation system, while a garbage collection system 

requires an explicit design of these components. 

The development of a garbage collector would be an 
interesting extension to the current design. Some of the 
considerations for a mark-and-sweep garbage collector are: 

• Structure access is required for the mark phase. This 

phase needs to access the following interpreter 

structures: 

1- The object table. 

2. The active rule table. 

3. Rules under evaluation by the console command 
processor. 

4- Rules under evaluation by the file command 

processor. 

5. Intermediate results generated during rule 

evaluation . 
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Accessing intermediate results is complicated by the 
present recursive implementation. A possible solution 
is to maintain a stack specifically for referencing 
these structures during a mark phase. 

• Cells require a mark bit. The current cell structure 
provides an 8 bit tag. Bits 0 through 5 are used for 
the tag value# bit 7 is used as a flag on certain 
structures. Bit 6 remains available for marking 
purposes. 

• Complete storage access is required for the sweep phase. 
This immediate access implies that the memory allocator 
must be managed by the interpreter. To maintain a 
reasonable virtual memory image, this allocator must 
obtain and release memory on page boundaries, using 
compaction whenever possible. 



G. EEDUCING CELL STORAGE 

The current 12 byte re-^uirement for cell storage is 
large. Since the cell structure is based on the LISP model, 
numerous LISP techniques may be used to reduce this 
requirement. 

LISP structures have fewer distinct cell types. Instead 
of encoding tag information directly, storage for cells of 
different types are often allocated from noncontiguous, 
separate sections of memory [Ref. 29]. In this way, the 
address range of a pointer provides the necessary type 
informa tion. 

List linearization techniques are another way to reduce 
storage requirements. These techniques attempt to maintain 
cells, normally linked via their tail pointers, in contig- 
uous storage. This allows a reduced tail field size, with a 
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field containing a cell offset to the next cell in the 
structure instead of a full pointer. An escape mechanism 
allows full pointer access where necessary [Eef. 30: p. 

266 ]. 

The above techniques are mentioned as potential improve- 
ments in the current allocation scheme. These techniques, 
like garbage collection, require more explicit control of 
storage allocation than is offered by the current design. 

A potential storage savings can be obtained with the 
current tagged cell structure by embedding the tag in the 
tail field. This is a simple modification that requires 
masking the tail field value to obtain the tag or tail 
pointer. If a reference counting field is not used 
(assuming garbage collection instead) this technique 
reduces the current cell requirement to 8 bytes, a 33 
percent reduction. Using this encoding scheme, the tail 
pointer is restricted to a 24 bit range. 
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VII. PEEFORMMCI EVALU^ION 



A. HETHCDOIOGY 

A progressive series of programs were developed to test 
features as they were implemented. These programs assisted 
in determining the interpreter's reliability and execution 
characteristics. Execution profiles and comparative bench- 
marks were used to evaluate behavior and performance. 

In this implementation, performance was subordinate to a 
clear, workable design. Performance optimization efforts 
were started only after the design and implementation of a 
series of features were complete, with all test programs 
successfully executing. 

1 . Execut i on Pr ofiling 

The gprof call graph execution profiler [Eef. 26] 
was an important tool for evaluating weak points in the 
performance of the interpreter. Execution profiles pointed 
out some immediate inefficiencies in the implementation that 
could be easily remedied. 

A simple example is the tag function. Initially, a 
function was used to extract the tag value from a cell. The 
rationale behind this implementation was information hiding: 
the details of the cell structure were accessible to only a 
few handling routines. 

Execution profiles on pattern-matching showed this 
implementation to be costly: the interpreter spent over 10 
percent of its execution time extracting tags. To solve 
this problem, the function was rewritten as a C macro 
[Ref. 22: p. 86]. The VAX instructions generated by the 
alternative implementations are shown in Figure 7.1. The 
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macro implementation results in a sayings of 4 

instructions — a substantial inprovement given the high 



Function Implementation 
C statements VAX instructions 

X = tag (p) ; 



[ 

^ return (p->tag) ; 



pushl -8 (fp) 
calls _tag 
movl r0,-4 (fp) 



cvtbl *4 (ap) , rO 
ret 



Macro Implementation 

C statements VAX instructions 

# define tag (x) (x->tag) 



X = tag (p) ; 



cvtbl *-8 (f p) /-4 (f p) 



Figure 7.1 Code generation for TAG function. 

frequency of tag extraction during interpretation. 

Replacing procedural implementations with macros is 
not a panacea. Macro implementation has at least two 
disadvantages: 

• Debugging is more difficult. Macros are textually 
expanded by a preprocessor before compilation. The 
errors that occur are unusual, do not correspond well 
with source code, and may produce unexpected effects. 

• Profiling information is lest. An execution profile 
pointed out the expense of the tag function. Once coded 
as a macro, the cost of this code sequence is absorbed 
in the routines where the macro is expanded. 
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2 . Ben chmark ing 

In this chapter we present a collection of simple 
benchmark programs. The performance of the Omega inter- 
preter is compared to interpreted Franz LISP, compiled Franz 
LISP, and the C-?rolog interpreter. The C-Prolog inter- 
preter is a VAX Prolog implementation descended from the 
DECsystem-1 0/20 Prolog system £Ref. 31 and 32]. These 
systems are all written in C. 

These benchmarks are net intended as an evaluation 
of C-Prolog or Franz LISP, and no effort has been made to 
write efficient Prolog or LISP. Because these systems are 
well-engineered and efficient in what they do, we present 
these benchmarks as an indication of the current progress of 
our implementation. The source code for the benchmarks is 
included in Appendix D. 

Timing information was obtained through calls to the 
date function of the UNIX command shell [Ref. 26]. The 
following Omega rule demonstrates this technique: 

if *gTest (a) -> { 

System {"date"} ; 

Qsort £IotaR[1 , 150]}; 

System {"date"} ; 

3 . 

The date function returns the current system time to the 
nearest second. The test systems all possessed a function 
similar to the Systea procedure shown above, and the over- 
head of executing such a system call should be consistent 
between interpreters. The timing granularity of one second 
required establishing benchmarks of sufficient duration to 
provide meaningful cemparisons. 
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3 . Omega S tatistic s 



Besides benchmark and profiling measurements, addi- 
tional information was collected to begin a characterization 
of Omega program behavior. This information included: 

• Data type frequencies. 

• Hash collisions in the object table. 

• Relation characteristics: relation cardinality and tuple 
cardinality. 

The last two areas are dynamic characteristics which change 
as rules fire and alter the database. These measurements 

were taken using a sampling technique: object table meas- 

urements were made immediately after each rule evaluation. 

B. TEST RESULTS 

Benchmark programs were tested using two different 
versions of the interpreter. The versions were: 

• The standard interpreter without reference counting. 

• A version compiled with the gprof profile option and 
containing object table and cell measurement routines. 

The overhead of measurement and profiling necessitated the 
separate compilations. 

The execution profiles produced by gprof are extensive. 
These are summarized and included in profile summary tables, 
with the profiling information for the five most expensive 
{in execution time) routines shown. The percentages given 
in these profile summaries are taken directly from the 
profile reports, and reflect the large overhead of the 
profiler. The profiling routines typically consumed about 
50 percent of the total execution time. Thus, if an 
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execution percentage for a routine is shown to be 5 percent, 
its relative impact is approximately 10 percent in unpro- 
filed execution. 



• h Pattern-M atchin g Test 



two rela- 
each. A 
The search 



This benchmark asserts a common tuple in 
tions, followed by 1000 disjoint assertions to 
pattern- match search finds the common tuple, 
requires more than 2 x 10® pattern-match tests, a worst-case 
performance. 

The Prolog version is similar, with assertions made 
to the Prolog rule base. Prolog searches the rule base from 
top to bottom. The common clauses are asserted and subseq- 
uent clauses placed before these using the asserta predicate 
[Ref. 21 ; p. 105 ]. 

We include a LISP implementation of a nested loops 
search, although this is a simplification of the pattern- 
matching process of Omega and Prolog. Only a compiled LISP 
version was tested because an interpreted version is at an 
unfair disadvantage when competing with the direct implemen- 
tations of this process. 

The timing results for this benchmark are shown in 
Table II. A summary of the Omega execution profile is shown 
in Table III, and type information is shown in Table IV. 
Relation characteristics are not shown for this test. 

2 . Pact or ia_l Functio ns 

This benchmark exercises the applicative component 
of the interpreter. A recursive factorial function is 
executed 500 times, with each call computing Fact[15]. 
Larger factorials are not used because both Franz LISP and 
Omega experience integer overflew in their computation. 

Timing results are shown in Table V, and an Omega 
execution profile summary in Table VI. Table VII shows the 
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TABLE II 

Execution Times: Pattern-matching 



1 



System 



Execution Time (secs) 



Omega . 212 

Prolog 10 2 

LISP 

Interpreted N/A 

Compiled 230 















TABLE III 




Execution Profile 


Summary: Pattern-matching 


% Execution 
Time 


No. 

Calls 


Nam 6 


Descr 


30.5 
10.0 
5.7 
4. 4 
0.9 


202 1016 
1010985 
5035 
1 00400 
70019 


uni fy 
equ 

mat ch s 

FreeBind 

eval 


pat tern- matching 
list equality test 
linear list search 
reset frame bindings 
evaluation function 

. 



Omega type distribution for this benchmark, and Table VIII 
shows the relation characteristics. 

3 • h. Number Siev e 

The third benchmark is a prime number generation 
program. The benchmarks use a sieve algorithm to remove 
prime number multiples from a list of numbers. This is an 
interesting benchmark for Omega in that the sieve is driven 
by rules, but the major compu tat ion--remo ving multiples--is 
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1 




TABLE 


IV 




Data 


Type Frequencies 


: Pattern-matching 




Type 


Frequency 


% of Total 




Lists 








Op List 


2053 


1 1 




Data List 


8815 


49 




Atoms 








Integer 


2028 


11 




String 


1 141 


6 




Boolean 


3004 


17 




Object 


235 


1 




Variable 


74 7 


4 


J 



TABLE V 

Execution Times: Factorial 



System 


Execution Time (secs) 


Omega 


23 


Prolog 

LISP 


99 


Interpreted 


12 


Compiled 


4 



performed by the applicative component. The Prolog version 
is based on an example given in [Ref. 21: p. 157], 

The timing results for this benchmark are shown in 
Table IX. These times are based on a sieve list of 350 inte- 
gers. A summary of the Omega execution profile is given in 
Table X, data type distributions are given in Table XI, and 
relation characteristics in Table XII. 



117 



TABLE ?I 

Execution Profile Summary; Factorial 



Execution 


No. 






Time 


Calls 


Nam € 


Descr 


14. 8 


155457 


eval 


evaluation function 


3.7 


32059 


malloc 


memory allocation 


3.2 


2400 1 


bin op 


binary operation 


2. 1 


30346 


newcell 


create a new cell 


1.9 


9097 


tupl 


eval tuple/args 





TABLE VII 






Data 


Type Frequencies: 


Factorial 




Type 


Frequency 


% of Total 




Lists 








Op List 


2001 


7 




Data List 


9777 


32 




Atoms 








Integer 


15530 


51 




String 


1607 


5 




Boolean 


502 


2 




Object 


226 


1 




Variable 


720 


2 





4 . Qui cksor t 

This benchmark exercises the Omega procedure call 
and pattern-matching mechanisxs. The Quicksort splits 
lists, recursively sorts the sublists, and combines the 
results. The Prolog version is taken from the example given 
in [Eef. 21; p. 147], 
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TABLE illl 

Omega Relation Characteristics: Factorial 



Sample Frequency; 2078 






Characteristic 


Mean 


Std Dev 


Mode 


Relation 

cardinality 


1.0 


0.0 


1. 0 


Tuple 

cardinality 


2.0 


0. 1 


2.0 


Object Table Collisions: 
Collision List Length 


Frequency 




1 




43126 







TABLE IX 




Execution 


Times; The Sieve 




System 


Execution Time (secs) 




Omega 


19 




Prolog 

LISP 


1 1 




Interpreted 


9 




Compiled 


3 


- 



The timing results are shown in Table XIII. These 
times are based on executing an ascending sort on a list of 
150 integers initially arranged in descending order (an 
0(n2) undertaking for Quicksort). An execution profile 
summary is given in Table XI7, and Table XV contains the 
data type frequencies. The relation characteristics of the 
benchmark are shown in Table XVI. 
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TABLE X 

Execution Profile Summary: The Sieve 
% Execution No. 



Time 


Calls 


Nam e 


Descr 


13.7 


1 1 8635 


eval 


evaluation function 


4.2 


16462 


tupl 


eval tuple/args 


4.0 


29425 


malloc 


memory allocation 


2.9 


28169 


new cell 


create new cell 


2.7 


12348 


fnapl 


apply fn to args 



TABLE XI 

Data Type Freguencies: The Sieve 



Type 

Lists 

Op List 
Data List 
Atoms 
Integer 
String 
Boolean 
Object 
Variable 



Frequency 


% of 


1990 


7 


20 37 2 


72 


3266 


12 


1146 


4 


423 


2 


23 2 


1 


76 1 


3 



5. A S im u la ti on P rogra m 

This example is a Monte Carlo simulation of a three 
node message switching network. It is a more complex 
program than the preceding benchmarks, and the interpreter 
exhibits a wider range of activities. The source code for 
the simulation rules is listed in Appendix E. 
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TABLE XII 

Omega Eelation Characteristics: The Sieve 



Sample Frequency: 


149 






Characteristic 


Mean 


Std Dev 


Mode 


Relation 

cardinality 


1.0 


0.0 


1.0 


Tuple 

cardinality 


2.6 


0.5 


3.0 


Object Table Collisions: 
Collision List Length 


Frequency 




1 




2694 





TABLE XIII 




Execution 


Times: Quicksort 




System 


Execution Time {secs) 




Omega 


142 




Prolog 

LISP 


27 




In terpr eted 


81 




Compiled 


40 


_ 



Comparative benchmarks were not written for this 
problem, and timing comparisons are not shown- The execu- 
tion profile for the simulation is given in Table XVII, data 
type frequencies are shown in Table XVIII, and relation 
statistics are shown in Table XIX. 
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TABLE 217 

Execution Profile Summary; Quicksort 
% Execution No. 



Time 


Calls 


Nam € 


Descr 


13.7 
5. 1 
2.7 
2.6 
2.0 


717396 
216385 
151009 
91975 
1 43777 


eval 
unify 
malloc 
tupl 
new cell 


evaluation function 
pa ttern-ma tching 
memory allocation 
eval tuple/args 
create new cell 





TABLE XV 






Data 


Type Frequencies; 


Quicksort 




Type 


Frequency 


% of Total 




Lists 








Op List 


1753 


1 




Data List 


121627 


85 




Atoms 








Integer 


170 


0 




String 


6820 


5 




Boolean 


11777 


8 




Ob ject 


533 


0 




Variable 


808 


1 





C. IHPACT OF REFERENCE COUNTING 

The timing information presented previously was taken 
without reference counting. A separate version of the 
interpreter was compiled with the reference counting 
routines included, and separate measurements taken. The 
impact of reference counting on execution speed is shown in 
Table XX. A summary of the Quicksort benchmark, with refer- 
ence counting implemented, is shown in Table XXI. 
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TABLE X?I 

Omega Relation Characteristics; Quicksort 



Sample Freguency; 


35704 






Characteristic 


Mean 


Std Dev 


Mode 


Relation 

cardinality 


1.0 


O 

• 

o 


1.0 


Tuple 

cardinality 


4.9 


0.7 


5.0 


Object Table Collisions: 
Collision List Length 


Freguency 




1 

2 




785578 

264 









TABLE I7II 




Execution Profile Summary 


: Simulation 


% Execution 


No. 






Time 


Calls 


Nam € 


Descr 


9.4 


21 1360 


eval 


evaluation function 


3.3 


63126 


unify 


pattern-matching 


2.9 


63782 


malloc 


memory allocation 


2. 1 


1221 


wri te 


system i/o 


1.8 


35220 


lookup 


hash table lookup 



D. DISCDSSIOH OF EESDLTS 

1 • Pe r form a nce Bo ttleneck s 

The measurements presented in the preceding sections 
provide some insight into the effectiveness of the present 
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TABLE XVIII 






Data 


Type Frequencies: 


Simulation 




Type 


Frequency 


% of Total 




Lists 








Op List 


6125 


1 1 




Data List 


26053 


47 




Atoms 








Integer 


2147 


4 




String 


6340 


1 1 




Boolean 


10124 


18 




Object 


2390 


4 




Variable 


2290 


4 


- 



TABLE XIX 

Omega Relation Characteristics: Simulation 



Sample Frequency; 


9972 


Characteristic 


Mean 


Eela tion 

cardinality 


5.7 


Tuple 

cardinality 


2.3 


Object Table Collisions: 
Collision List Length 



1 

2 

3 

4 

5 

6 



Std Dev 


Mode 


6. 3 


1.0 


0.7 


o 

• 

CM 


Frequency 




404828 
180974 
26152 
4552 
2761 
1 1 





implementation. The execution speeds for the Omega bench- 
marks are consistently slower than C-Prolog and Franz LISP. 
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TABLE XX 

Reference Counting and Execution Times 



Benchmark 


w/o Ref Counts 


w Ref Counts 


%Incr 


Pattern 

match 


212 


223 


5 


Factorial 


23 


30 


30 


Sieve 


19 


25 


32 


Quicksort 


142 


181 


27 



TABLE XII 

Profile of Quicksort with Reference Counting 
% Execution Ho. 



Time 


Calls 


Nam € 


Descr 


9.9 


717396 


eval 


evaluation function 


4.0 


216385 


uni fy 


pattern-matching 


3.7 


421556 


DecrSef 


decrement ref count 


3.3 


541624 


IncrRef 


increment ref count 


2.4 


151009 


mal loc 


memory allocation 



This performance is shown in both applicative expression and 
rule evaluation. 

The central evaluation function, eval, consumes the 
majority of execution time. This is not surprising given 
the present recursive implementation: eval is called 

directly or indirectly in most operations. Embedded in eval 
are accesses of the binding stack for atom evaluation in 
tuples and argument lists. 

The high frequency of calls to eval suggest its 
design as a potential point for optimization. This 
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optimization may include a reduction of unnecessary recur- 
sive calls to eval. When evaluating interior^, nodes of a 
rule tree, the sons of a node are always passed to eval, 
which will decode the tag and call the appropriate subordi- 
nate routine. If the required subordinate routine is known 
at the parent node, the intermediate call to eval may be 
omitted . 

Another alternative is to replace the recursive eval 
with an iterative version. This requires the management of 
an explicit operand stack, and involves a major redesign 
effort. The management of an operand stack would, however, 
solve an implementation problem for garbage collection 
discussed in the previous chapter. 

The pattern- matching routine becomes significant in 
extended rule processing, as shown by the Quicksort and 
network simulation tests. Re note similarities between eval 
and the pattern- matching routine unify; 

• Both routines are heavily exercised. 

• Both routines access the binding stack when evaluating 
free variables. 

• Both routines are recursive. 

The recursive algorithm for pattern-matching is simple and 
elegant. An iterative version would be more complex, but 
may provide a performance gain. 

A final area for performance improvement is storage 
management. The storage allocation routine, malloc, and 
routines that call it, such as newcell, consistently rank 
high in the execution profiles. Our implementation of 
reference counting for storage reclamation proved to be 
expensive, with a 30 percent ircrease in execution time for 
extended tests. These results make garbage collection 
appear to be a desirable alternative. Hardware support for 
reference counting could also provide a solution. 
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2 • Sta tisti cs 

The statistical information gathered on relations 
provides some evidence to support previous conjectures: 

• Small relations are commonplace. The mode for relation 
cardinality was 1.0 in every test. These statistics 
will vary depending on the application, and generaliza- 
tions can't yet be made based on the limited tests 
conducted. 

• Object identifiers hash well. The object table colli- 
sion results indicate an even distribution of hash 
values. Collisions in the object table slow down rela- 
tion list lookup, an important part of the synchronous 
procedure call. Only in the simulation test did hash 
table lookups begin to become significant in the execu- 
tion profiles. This coincides with the increased number 
of objects generated and an increased collision 
frequency in the object table. 
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7III. OBSERVATIONS, H ECOMlllDATIOliS, AND C^CLOSIONS 

A. OBSERVATIONS ON CHEGA 

Experience 

Our experience with Omega programming is reflected 
in the rules listed in Appendices C-E. We believe these 
examples demonstrate a variety of applications which have 
simple solutions in Omega rules. 

An important body of rules are the system utilities 
listed in Appendix C. Included are relation copying utili- 
ties, an extension to the system pretty printer, and a help 
facility. The last application shows a simple use of the 
System procedure call to list help files at the user's 
terminal. This technique could be extended to use the Omega 
interpreter as a rule-based driver for the UNIX command 
shell . 

The longest and most significant application is the 
simulation model listed in Appendix E and profiled in the 
previous chapter. Ke include this example as an event- 
driven, state-transition problem which is readily expressed 
as rules of the form: 

if Clock (t1), *Event{t1, e) -> 

ProcessEvent [e] . 

2 . Ome^a an_d P rolo g 

The benchmarking examples of the previous chapter 
presented rules in Prolog and Omega that are similar in 
form. Both these languages use pattern-directed invocation 
for rule selection, and both languages are intended for 
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general programming applications. Despite similarities, 
these languages have fundamental differences. 

Omega uses forward inference, Prolog uses backward 
inference; Omega programmers and Prolog programmers think 
in different directions. To design an Omega rule, one uses 
the train of thought: "Given the current state of the 

system, generate the next state." A Prolog rule is designed 
with the thought: "To prove this goal, it is necessary to 

prove these subgoals." Prolog relies on a theorem-proving 
approach. Omega on a data-driven approach. 

These opposite control strategies are reflected in 
different implementation technigues: 

• Prolog recursively evaluates its rules from a goal 
stack. This technique often allows intermediate storage 
allocation from stack structures. This method of allo- 
cation and reclamation is simpler than the heap alloca- 
tion used by Omega and LISP, and results in a faster 
cons operation [ Eef . 32: p. 114]. This performance is 
reflected in the Quicksort benchmark of the previous 
chapter. 

• Theorem proving requires backtracking. Prolog selects 
rules from its rule base to prove subgoais. If multiple 
rules for a subgoal are present, they will be selected 
and tested until the subgoal is proven or all possible 
rules fail. Backtracking between rules requires a more 
general pattern- matching technique in Prolog than Omega. 
In Prolog, variables may he bound to variables. In 
Omega, a rule fires or it doesn’t — there is no require- 
ment for backtracking between rules, and variables are 
bound only to objects and values in the database. 

Programming problems may be solved by either forward 
or backward inference. To illustrate this point, we use the 
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missionaries and cannibals problem [fief. 33: p. 51], a 

simple state-space search example. The Omega and Prolog 
rules for this problem are listed in Appendix D. 

In the missionaries and cannibals problem, a simpli- 
fied description of the Omega rules is: 

if *State (x, path), GoalState[x] -> 

Displayn {path} 

else if *State (x,path) , Is IegalState[ x ] , 

-•member[x, path] -> 

GenerateNewStates [x,[ x:path]} 
else if *State (x,path) ->. 

Given a starting state, the Onega rules will generate all 
possible new states that may be reached from that state. 
This process continues until all combinations of legal 
states have been tested. IJo backtracking is required in 
these rules — successful states continue to fire, and unsuc- 
cessful states are removed from the computation. We main- 
tain a list of previous states in the variable path to 
prevent cycles. 

A simplified version of the Prolog rules for this 
problem is: 

goals tate (X , Path) :- 
finals tate (X) , 
print (Path) . 
goals tate (X , Path) :- 

not member (X,Path) , 
legalState (X) , 
possibleNextState (X, Y) , 
goalState {Y,[ X] Path]) . 

In the Prolog version, the predicate possibleNextState will 
bind the variable Y to a new state that can be reached from 
X. In its attempt tc "prove” the starting goal state, all 
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possible state combinations will be generated by back- 
tracking on possibleUextState. We observe Prolog exploring 
new states through backtracking where Omega relies cn the 
generation of new states in the database. 

Certain classes of problems lend themselves well to 
the natural recursion inherent in Prolog. The Quicksort 
rules of Appendix D are a model of brevity and clarity. We 
suggest that event-driven or data-driven applications, such 
as the simulation example of Appendix E, are better 
described through Omega. Omega was developed as a high- 
level language for programming environment description and 
implementation. This family of applications are represented 
more naturally through forward inference descrip tions. 

3 • The Pr o duc ti on Ru le as a Programming Paradigm 



Both Omega and Prolog use the production rule as the 
programming paradigm. How easy is it to program with 
production rules? We consider this to be an application- 
dependent quality. A problem can be effectively described 
with production rules if the following characteristics 
apply : 

• The problem can be decomposed into a set of small, 
cause/effect subproblems. Each subproblem is described 
by a single rule or small set of rules. 

• The subproblems are independent, and require minimal 
communication between rules. 

The independence of rules allows the programmer to 
add or remove rules without concern for the impact of these 
changes on other rules in the active rule list. In our 
current design, the rule denctation is the unit of rule 
organization. Thus, a goal for a manageable rule structure 
is independence of rule denotation sets. 



A significaDt limitaticn of most production rule 
systems is a lack of meaningful semantic composition, the 
inability to compose a complex action from a collection of 
previously defined simpler actions. Rosenchein writes: 



[In production systems] tests and transformations are 
sophisticated and are designed to implement constructs 
found in various applications. However, there is gener- 
ally no way to symbolize composition of operations in a 
transparent way. Complicated tests and actions have to 
be simulated by groups of rules whose coordination is 
not symbolized in the program or graced with a mnemonic 
name. The more complicated the tests and actions, the 
more severe the coordination problems. This is typical 
of programs written at one level of abstraction, no 
matter how sophisticated the primitive operations. 
[Ref. 34; p. 535] 



Omega provides some potential solutions to this 
problem. The object-oriented approach of the language 
allows the partitioning of related data and rules through 
directories and classes. This organization of the name 
space provides the first step in a hierarchical composition 
of rule activity. 

The second step is the procedure call mechanism. 
This mechanism serves as an invocation trigger for a collec- 
tion of rules, with a method of integrating the outcome from 
their actions into more complex expressions. The utility of 
this mechanism is indicated by its widespread use in the 
examples presented in this thesis. 

Although our programming examples are dependent on 
the procedure call, we note potential problems with the 
mechanism: 

• The actions associated with a procedure call may not be 
obvious. The procedure call asserts a tuple to a given 
relation, and extracts the response from its mailbox. 
Multiple rule denotations may use the procedure’s rela- 
tion, and fire as a result of the procedure assertion; 
the possibilities for subtle side effects are 
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significant. The final effect of a procedure call can 
only be determined from an analysis of all rules associ- 
ated with the procedure’s relation name (as defined in 
its directory) . 

• The procedure mechanism does not enforce parameter 
checks. The tuple asserted in a procedure call is anal- 
ogous to the actual parameters of a conventional proce- 
dure call. In Omega, there is no parameter counting or 
type checking. Consider the following rule: 

if *E(a, X) -> displayn {x} . 

If the user mistakenly enters ”R(100)," the assertion 
will be made but the rule will not fire because of a 
pattern-matching failure. The procedure call '’R{100, 
200}” will fail for the same reason. In both of these 
situations, no error indication will be given. 

There are programming techniques that correct the 
last problem. If we code the rule as; 

if *R(a:l) -> . - . 

the head/tail list specification will match against any 
tuple. The rule designer may then code explicit type and 
parameter count checks with an appropriate response to 
errors. We use this technique in the utility rules 
contained in Appendix C. 

A declarative mechanism may also be used to specify 
the expected tuple size for a given relation. Any devia- 
tions would trigger an error response. 
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B. EECOHHEBDED AREAS FOE ADDITIONAL STUDY 



1 . 



Ex tens ions to th e Lang uaqe 



Our programming and implementation experience with 
Omega have suggested three additional extensions to the 
language; (1) a syntactic distinction for free variables, 
(2) a universal quantifier, and (3) named rules. 

In our current implementation, the distinction 
between free and bound variables is made when rules are 
activated; if defined in the class/directory structure, the 
variable is bound; if not defined, it is considered free. 

This strategy is a potential source of error. 
Suppose we wish to define a constant, and use the following 
definition: 

Define {Root, "a", 100}. 

The selection of the variable name a will conflict with the 
majority of our rule denotations, where this variable is 
consistently used to represent a mailbox relation. The 
activation and test of the following rule: 

if *T (a, X) -> a (2 ♦ X) . 

will result in a type clash error. These errors are subtle, 
and require the programmer to remember which names are 
previously defined in a given environment. To solve this 
problem, free variables should be syntactically distin- 
guished. Thus, the preceding rule may be written; 

if *T (&a, &x) -> Sa(2 ♦ &x). 

Previous definitions cannot adversely affect this rule. 
C-Prolog uses a similar convention; free variable names 
begin with upper case letters, bound variable names begin 
with lower case letters. 
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In Chapter 2, we emphasized the point that a rela- 
tion inquiry is existentially quantified. Consider the 
following rule: 

if CopyHel{r1, t 2) , r1 (x) , -*r2 (x) -> 
r2 (X) 

else if *CopyRel(r1, r2) ->. 

This rule implements a relation copying utility. The 
programmer’s intent for this rule is that all tuples in r1 
should be asserted to relation r2. Existential quantifica- 
tion will select a single tuple on each firing cycle for the 
rule. Note that the absence test on relation r2 is required 
to ensure termination. 

A possible alternative is to provide universal quan- 
tification for tuple selection. With this mechanism, the 
copy rule could be written: 

if *CopyRel (r1, r2) , $r1 (x) -> r2 (x) . 

The ’*$" symbol is used to represent universal quantifica- 
tion. The action of the quantifier is "for all tuples x in 
relation r1, assert x to relation r2." A universal quanti- 
fier offers the following advantages: 

• The programmer’s intentions are more clearly expressed. 
There is a similarity between universal quantification 
and the mapcar function of LISP. 

• Performance may be enhanced. A universal quantifier 
allows optimization by completing the actions of the 
rule in one rule cycle. The costs of multiple rule 
selection and testing, shown in the profiles of the 
unify procedure in the preceding chapter, may be high. 

It is recognized that the existential quantification 
of the present design is sufficient to accomplish the 
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intended function of the CopyEel rules and similar applica- 
tions. The advantages of universal quantification must be 
weighed against the added complexity to the language. 

It would be useful to be able to reference rules by 
name. The rule forms the basic computational unit in the 
language, yet may net be referenced explicitly; the only 
named reference for a rule is its source rule denotation. 
If the denotation is large, its name is not a selective 
description. If a single rule is to be manipulated, perhaps 
by a structure editor, the entire denotation must be 
accessed. A similar problem is experienced with activating 
and deactivating rule denotations. 

2. Ext ensi ons to the Pr esent Interpre ter Design 

Our present implementation includes the majority of 
Omega language features described in [Eef. 14]. Several 
possible extensions to the present implementation are of 
interest. 

The class mechanism described in Chapters II and IV 
is not currently implemented. The present system provides a 
single directory, root, frequently referenced in our exam- 
ples. The class and directory structures, with rules 
indexed on relation objects, provide the inheritance mecha- 
nism for the language. The implementation of classes as 
binding lookup paths will allow a more thorough exploration 
of the object-oriented nature of Omega than has been 
provided in this work. 

Both the LISP prototype and the current prototype 
use a simple linked-list relation structure. There are two 
alternate representations that are of immediate interest; 

• Hashed indexing of relation lists. Relations lists are 
currently selected via hashed access of the object 
table. A performance-enhancing extension to this 
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techni< 3 ue is to provide a hashed index structure for 
tuples within a relation, possibly using a user- 
specified key or arbitrarily using the first tuple 
member as a key. An indexed relation structure would 
have little impact on most of the benchmarks of the 
preceding chapter (except the pattern-matching test) 
because of the small relation sizes. A substantial 
performance improvement for inquiries on larger rela- 
tions may be realized. 

• A relational DBMS implementation of relations. The 
current design can be extended to include a query and 
response translation interface with a concurrently 
executing DBMS. The interface could be organized around 
object identifier recognition, as system objects are 
currently handled. The tag field of DBMS-supported 
objects could be assigned a unique value to route these 
objects to the DBMS interface instead of the normal 
relation management routines. 

Control strategies for rule selection and test 
remain an open subject in this work. Our two-level trig- 
gering strategy, discussed in Chapter V, was selected as a 
compromise implementation that provides a reasonable level 
of rule selection precision under a programmer's control. 
Full indexing of rules — triggering on all the relations in 
the rule antecedent--was not attempted. The performance of 
full indexing compared to two-level triggering is a poten- 
tial point for additional study. 

The control strategy of Omega, like Prolog, is 
"hard-wired” into the interpreter design. The designs of 
several other rule-based systems have taken a more flexible 
approach: meta-rules dictate control strategies [Ref. 35]. 

The idea of integrating rule-based control strategies into 
Omega would be an interesting extension to the language and 
its interpretation. 



137 



The space considerations of Chapter VI, as well as 
the execution statistics of Chapter VII, indicate that a 
garbage collection scheme may preferable to reference 
counting. The implementation of an efficient compacting 
garbage collector can provide significant performance 
improvements. 

A useful extension to our implementation would be a 
flexible debugger. We currently use a trace facility that 
provides a display of rule execution. While this facility 
is useful, the information provided is not specific enough. 
The following debugging features would be helpful: 

• Specification of trace and break points by relation 
name. When a tuple is added or removed from a relation, 
the debugger may be invoked and the bindings of vari- 
ables available for examination. 

• Specification of trace and break points for specific 
rules. This facility is similar to the preceding one, 
but only certain rules are monitored. Note that the 
lack of names for individual rules makes this feature 
difficult to implement. 

• Debugger invocation on error conditions. As in the LISP 
prototype, error conditions result in an error message 
and a return to the interpreter's top level. The imple- 
mentation of a debugger would allow a more sophisticated 
respon se. 

Our present method for rule creation and modifica- 
tion should be extended. Currently, the following steps are 
used to create rules: 

• Command rules are entered into a file using a standard 
text editor. The vi procedure call is provided in Omega 
to allow ready access to the UNIX editor of the same 
name [Ref- 26]. 
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• The file is parsed using the file command reader, 
invoked with the Do procedure call. 

• Any rule denotations contained in the command rules are 
then activated. 

This process requires rule files to be reloaded each 
time the interpreter is run. Also, the current implementa- 
tion allows rule activation but not deactivation. These 
limitations suggest the following extensions; 

• A save/restore facility. This facility would copy and 
restore the virtual memory image of the interpreter’s 
data segment. 

• A structure editor. There is currently no way to edit 
rule denotations once they are loaded into the inter- 
preter. A structure editor would be useful, particu- 
larly when debugging. 

• Eule deactivation. The ability to remove rules from 
active status is necessary to allow testing and modifi- 
cation. The use of rule names would simplify this 
process . 

3. l^rallelism in Omeg a 

The prototypes discussed in this work have been 
sequential, single- threaded control implementations. An 
important extension to this work is the exploration of 
parallelism in Omega rule interpretation, with architectures 
tailored for concurrent rule evaluation. 

Parallelism in Omega shares similarities with paral- 
lelism in Prolog. The Prolog literature divides this paral- 
lelism in two categories; AND parallelism (where multiple 
subgoals in a rule are evaluated concurrently), and OR 
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parallelism (where multiple rules for a goal are evaluated 
concurrently) [Ref. 36: p. 29]. 

In Omega, AND parallelism may be exploited in both 
the antecedent and consequent of a rule. In the antecedent, 
inquiries must be independent for concurrent evaluation. 
Consider the following rule: 

if *R1(x), *R2(x), *R3(y) -> R3 (x+y) . 

The first two inquiries, Rl(x) and R2 (x) , are mutually 
dependent on the variable x. An evaluation order for these 
inquiries should be made to allcw the binding for the vari- 
able X to guide the relation search. The third inquiry, 
E3 (y) , is independent of evaluation order. An AND parallel 
strategy should separate a rule antecedent into independent 
subunits that exploit concurrency where possible. 

The evaluation of actions in the consequent of a 
rule has fewer constraints. Any actions separated by commas 
are potentially subject to concurrent evaluation. The 
actions of a sequential block are, however, restricted to a 
mandatory evaluation order. 

The evaluation of separate rules in Omega is unord- 
ered; OR parallelism is the norm for the Omega model. A 
parallel implementation of rule evaluation is complicated by 
the shared memory access that many rules require. This 
shared access implies a locking mechanism at the relation 
level, along with a deadlock-prevention strategy. 

The exploitation of parallelism in Omega offers the 
potential for the resolution of our present performance 
bottlenecks. A parallel architecture that optimizes 
pattern-matching and concurrent rule evaluation would yield 
substantial performance improvements. 
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C. CONCIUSIONS 



This thesis has described two prototype implementations 
of Omega interpreters, based cn the model of a LISP-like 
list processing system. Through these designs, we have 
developed a complete 1L{1)/LE(1) grammar, and implemented a 
table-driven parser using the YkCC parser generator. Many 
of the design and implementation problems encountered are 
similar to the LISP design issues of the literature. 

The unconventional component of Omega is its pattern- 
directed set of active rules. Our implementation processes 
these rules by a simple triggering method of rule indexing 
based on relation identifiers. Triggering, along with the 
processing of multiple rule queues, simulates the concurrent 
evaluation of rules in the Omega model. 

An evaluation of our interpreter's performance indicates 
current execution speeds are slower than Franz LISP and 
C-Prolog. Possible bottlenecks include excessive recursive 
calls to the central evaluation function, inefficiencies in 
pattern-matching, and execution penalties in storage manage- 
ment routines. While the present design may be optimized to 
improve this performance, other issues are of more interest 
in future research. These issues include alternative repre- 
sentations of relations, alternative control strategies for 
forward inference rule systems, and the exploitation of 
parallelism in Omega. 

Our final contribution in this work is a body of Omega 
programs and some statistical information on their behavior. 
As the Omega language matures, this experience may help to 
characterize potential extensions and improvements to the 
language and its implementation. 
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APPMPII i 

LEX AND lACC SPECIFICATIONS FOR OMEGA 

4 : 4 ! ♦ 4 * ** 4 : 4 : 4 : 4 = 4 = 4 = 4 : 4 = 4 : 4 : 44 : 4 ! 4 : 4 = 4:4 4 4=4 



4 4 

* LEX specification -- ♦ 

* Omega lexical grammar * 

4 4 



444444 44 44 4444 4 44 4444444 444 44 4 44 44 4444 44 44 44444 44 44 444/ 

/* lexical scanner grammar */ 



digit 


[0-9] 


Ittr 


[ a-z A-Z ] 


whitespace 


[ \t \n ] 


identifier 


{Ittr} ( { {Ittr} 1 {digit} | _) * { {Ittr} | {digit} ) ) * 


int_con 


{digit} + 


delimiter 


[-+! 1,. ; 'SO {}*/%-.& :=<>_]! \[ 1 \] 


implication 


-> 


deno 


« 


end_deno 


» 


ne 


“1= 


le 


<= 


ge 


>= 


int_con 


{digit} + 


str_con 


\ll £/\ll ] 4 \H 


comment 


\! [^\n ]*\n 



%% 

/4 recognizer actions fcr token classes */ 



int c; 
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{identifier} 



{ 



} 


if (str egu (yytext, "if")) 
return (IF) ; 

else if (stregu (yytext , "else")) 
return (ELSE) ; 

else if (stregu (yytext , "fn")) 

return (FUNCTION) ; 
else if (stregu (yytext, "Nil")) 
ret um (NIL) ; 
else 

return (IDENTIFIER) ; 


{int_con} { 


return (INT_CON) ; 


} 




{str_con} { 


c = input 0 ; 
if (c == *\"') { 

unput(c) ; 

— yyleng ; 
yymore () ; 

} 

else { 

unput(c) ; 
return (STR_CON) ; 
} 


} 




{implication} { 


return (IMPLICATION) ; 


} 
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{deno} 


£ 

return (EEG_DENO) ; 




} 


{end_deno} 


£ 

return (END_DENO) ; 




3 


{ne} 


f 




return (NE) ; 




} 


£le} 


f 

return (IE) ; 




} 


{ge} 


£ 




return (GE) ; 




3 


{delimiter} 


£ 

return (yytext[0 ]) ; 

3 


{comment} 


f 


{whitespace} 


f 



/* ignore others ♦/ 

%% 

stregu(s1, s2) 
char *s1, *s2; 

{ 

return (strcmp (si , s2) == 0) ; 

} 
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tracefun (msg) 
char *msg; 

{ 

printf (" \n* **5is*** — > "^msg}; 
ECHO; 

printf (" \n" ) ; 



❖ 

* YACC Specification for Omega Parser * 

* * 

❖ ❖❖ ^ 3jt :f: :$c * :^c 3?t 3^: 4^ ❖ * 3}c :$e :^c :}c :^c 

%{ 

# include "tag.h" 

# include "defs. h" 

PTE newcell () ; 

PTE makint () ; 

PTE makstr () ; 

PTE parsetree; 
char *strdeno (} ; 

%} 

/* type declarations for parser stack */ 

bunion { 

PTE cell; 

3 

%type <cell> session statement_list 
5Stype <cell> statement cpd_rule rule cause 
%type <cell> conditions condition inquiry 
5Jtype <cell> constraint transaction transactions 
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denial 



?5type <cell> effect assertion 

%type <cell> arguments seg_block 

%type <cell> unop binop 

%type <cell> rule_denotation 
%type <cell> variable self_ref 

%type <cell> f n_def inition 
%type <cell> f n_application 
%type <cell> cond_expr cpd_expr 

/* token declarations */ 



5Stoken IDENTIFIER 

%token IF ELSE 

%token STR_CON INT_CON 

%token IMPLICATION BEG_DENC 

%token NE LE 

55token FUNCTION NIL 



/* operator precedance */ 
Ueft 

%left expression 
551eft list 
%left 'S’ 'I' 

%left 

??left ’ = ' *<’ ’>' NE LE GE 

?:ieft '+' 

%left '/' ’%• 



expression 

primary 

constant 

fn_head 

list 

call 



END_DENO 

GE 



%start session 






/* productions for Omega grammar 
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session 



statement 



stat ement 



: /* empty */ 

{ 

parsetree = Nil; 

} 

I 

{ 

parsetree = Nil; 
return (- 1) ; 

} 

1 statement_list ' . * 

£ 

parsetree = $1; 
return (- 1) ; 

} 

f 

list : statement 

{ 

$$=newcell (STA_LIST ,Nil ,$ 1) 

} 

I statement_list statement 

£ 

$$=newcell {STA_LIST,$1 , $3) ; 

} 



cpd_r ule 

£ 

$$ = $1; 
} 

I fn_def inition 

£ 

$$ = $ 1 ; 
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} 



f 



cpd_rule ; 

1 


rule 

{ 

$$=newcell (CPD_RULE,Nil,$1) 
} 

cpd_rul€ ELSE rule 

C 

$$=newcell (CPD_RULE, $1, 13) ; 
} 



f 



rule : 


IF cause IMPLICATION effect 
£ 

$$=newcell (RULE, $2, $4) ; 
} 


1 


IF cause IMPLICATION 
£ 

$$ = newcell (RULE , $2 , Nil) ; 
} 


1 

1 


IMPLICATION effect 
£ 

$$=newcell (RULE, Nil, $2) ; 
} 

effect 

£ 

$$=newcell (RULE, Nil, $1) ; 
} 



9 



cause : 


conditions 

£ 

$$ = $1; 
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} 



conditions ; condition 

C 

$$=newcell (CONDS ,Nil 1 ) ; 

} 

1 constraint 

$$=newcell (CONDS , Nil 1 ) ; 

} 

I conditions condition 

£ 

$$=newcell (CONDS , $1, $3) 

} 

I conditions constraint 

£ 

$$=newcell (CONDS , $1, $3j 

} 

f 

condition : inquiry 

£ 

$$=newceil (CANC, $2,Nil) ; 

} 

I inquiry 

£ 

$$=newcell (ABST, $2,Nil) ; 

1 

I inquiry 

£ 

$$=newcell (PRES, $1 , Nil) ; 

} 

f 
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inquiry 


: primary ’ (’ arguments ’) ’ 

{ 

$$=newcell (INQY, $1 , 33) ; 
} 

f 



constraint 


; expression 

£ 

$$=newcell (CONSTR, $1 ,Nil) 

3 

f 


effect 


: transactions 

£ 

3$ = 31; 
3 

f 


transactions 


: transaction 

£ 

33=newcell (TRANS , Nil , 3 1 ) ; 
3 

i transactions transaction 

£ 

3$=newcell (TRANS , $ 1 , $3) ; 

3 

t 


transaction 


: assertion 

£ 

33 = $1; 
3 

1 denial 
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I 



assertion 



denial 



fn definition 



fn head 



C 

$$ = $ 1 ; 

} 

expression 

$$ = $ 1 ; 

} 

seg_block 

C 

$$ = $1; 

} 

primary ’ (' arguments ’) ' 

{ 

$$ = newcell (ASSER T, $ 1 , $3) 

} 

primary '(' arguments •) ' 

{ 

$$=newcell (DENY, $2, $4) ; 

} 

FUNCTION fn_head cpd_expr 

£ 

$$=newcell (FN,$2 ,$4) ; 

} 

' [ ' arg uments * ] ’ 

£ 

$$=newcell (FNDCL , Nil , $2) 

} 

primary '[' arguments 

£ 
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$$=newcell (FNDCL ,$ 1, $3) ; 





} 

f 


arguments 


: /* empty */ 

£ 

$$ = Nil; 

} 

1 list 

£ 

$$ = $1; 

} 

1 expression expression 

£ 

$$=newcell (CONS, $1, $3) ; 

} 

f 


list 


: expression 

£ 

$$=newcell (LIST, Nil, $1) ; 
} 

1 list ' , ' expression 

£ 

$$=newcell (LIST, $1 ,$3) ; 

} 

f 



seg_blocX 


: ' £* St atement_list '} ' 

£ 



$$=newcell (SEQ_BLK,$2,Nil) 

} 
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1 ’ statement_lis t *}' 

C 

$$ = newcell (SEQ_BLK , $2, Nil) 

} 

f 

expression : primary 

{ 

$ $ = $ 1 ; 

} 

I constant 

{ 

$$ = $ 1 ; 

} 

1 call 

{ 

$$ = $ 1 ; 

} 

I fn_application 

{ 

$$ = $ 1 ; 

} 

I rule_denotation 

$$ = $ 1 ; 

} 

I unop 

{ 

$ 2 — j> 1 j 

} 

1 binop 

C 

$$ = $1 ; 

} 

I ’ ( ' cpd_expr ’ ) ’ 
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$ 2 ; 



fn_application : 



call 



rule denotation : 



{ 

$$ = 

} 

'[ ' list ' ]' 

C 

$$ = $2; 

} 

'[' expression expression ']' 

{ 

$$=newcell (CONS, $2, $4) ; 

} 

{ 

$$ = Nil; 

3 



primary '[' arguments ']' 

{ 

l$=newcell (APL,$1,$3) ; 

3 

primary ' {' arguments '} ’ 

{ 

$$=newcell (CALL , $ 1 , $ 3) ; 

3 

BEG_DENO statement_list END_DENO 

£ 

$$=newcell (DEN0,S2,Nil) ; 

3 

BEG_DENC statement_list END_DENO 

£ 
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$$=newcell (DENO/ $2 , Nil) ; 

} 



f 



unop ; 

1 


'+' expression /oprec 

C 

$$ = $ 2 ; 

} 

»-• expression %prec 

C 

$$=newcell (ONHINUS , $2 , Nil) 
} 


1 


expression 

{ 

$$=newcell (NOT, $2, Nil) ; 
} 



f 



binop : 


expression ’+' expression 
( 

$$=newcell (PLUS, $1 , $3) ; 
} 


1 

1 

1 

1 


expression expression 

{ 

$$=newcell (MINUS, $1, $3) ; 
} 

expression expression 

£ 

$$=newcell (MULT, $1, $3) ; 

) 

expression V’ expression 
£ 

$$=newcell (DIV,$ 1, $3) ; 

} 

expression ’55’ expression 
£ 
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$$=newcell (MOD,$ 1,$3) 

] 

1 expression ’=’ expression 

{ 

$$=newcell (EQU,$ 1 ,$3) 

} 

I expression expression 

{ 

$$=newcell (LT,$1 ,$3) ; 

} 

I expression expression 

{ 

$$=newcell {GT,$1 ,$3) ; 

3 

1 expression NE expression 

( 

$$=newcell (NEQ,$1,$3) 

) 

1 expression LE expression 

C 

$$=newcell (LEQ,31,$3) 

} 

I expression GE expression 

{ 

$$=newcell (GEQ,$ 1 ,$3) 

3 

1 expression ’&* expression 

{ 

$$=newcell (AND,$1 ,$3) 

3 

I expression ’J’ expression 

{ 

$$=newcell (0R,$1 ,$3) ; 

3 
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f 



primary : variable 

{ 

$$ = $ 1 ; 

3 

I self_ref 

{ 

$$ = $ 1 ; 

3 

t 

self_ref : 'S' variable 

£ 

$$=newcell (SELF_REF ,i2. Nil) 

3 



variable : IDENTIFIER 

£ 

parsetree = makstr (yytext) ; 
$$=newcell (VAR, Nil# parsetree) ; 

3 

t 

constant : STR_CON 

£ 

$3 = makstr (strdeno (yytext) ) ; 

3 

I INT_CON 

£ 

$$ = makint (atoi (yytext) ) ; 

3 

I NIL 

£ 

$$ = Nil; 
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} 



f 



cpd_expr : 


cond_expr 

£ 

$$=newcell (CPD_R0LE,Nil,$1) ; 
} 


1 


cpd_expr ELSE cond_expr 
£ 

$$=newcell (CPD_RULE,$1 , ; 
} 


9 




cond_expr : 

1 


expression 

£ 

$$=newcell (RULE, Nil, $1) ; 

} 

IF constraint IMPLICATION expression 
£ 

3$=newcell (ROLE, 32, S4) ; 

} 


9 
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/0/t) 



/* user defined functions ♦/ 
# include "lex.yy.c" 



/* string denotation routine 

Lexical scanner returns string constants 
with " delimiters included. 

Denotation routine simply removes the extra "s. 




char *strdeno(s2) 
char *s2 ; 

char *s 1 ; 
si = s2 + 1 ; 

* (si + (s trlen (si) - 1) ) = '\0'; 
return (si); 

) 

/* error handler 

Prints error message and line number where error occurred. 
No attempt made to recover from errors. 

<=/ 

yy error (msg) 
char *msg; 

{ 

printf (”%s ; ”, msg) ; 

printf ("line %d\n”, yylineno) ; 

3 
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APP ENDIX B 

BOILT-IM FDNCTIONS AND PROCEDORES 



Built-in Functions 
A. Infix operators — 
op type 

+ str X str -> str 

+ int X int -> int 

— II 

4c II 

% " (modulus) 

/ '• 

< int X int -> Bool 

> " 

<= •' 

>= " 

= any x any -> Bool 

-•= any x any -> Bool 

& Bool X Bcol -> Bool 

1 Bool X Bcol -> Bool 

Onary operators : 

Int -> Int 

-« Bool -> Bool 



B. System defined functions ; 

Islnt[item] — Returns TRUE if 

is an integer. 



(concatenation) 



item 



IsStr[ item ] 



Returns TRUE if item 



is a string. 

IsList[ item ] — Returns TRUE if item 

is a list. 



IsOb j[ item ] 



IsEel[ item ] 



int_str£ int ] 



— Returns TRUE if item 
is an object. 

— Returns TRUE if item 
is a relation object. 

— Integer to string conversion. 



first[ list ] 



— CAR. Returns the first member 
of a list. 



rest[ list ] 



— CDR. Returns all members of 
a list after the first member. 



cons[x, 1] -- Returns a new list with x as its 

first member and 1 as the rest of 
the list. The notation [x:l] 
does the same thing. 



objval[ object ] — Returns the value bound to an 

object. 

The following objects have bound values : 

rela tions 

functions 

rule denotations 

directories 



Tag£form] — Returns a string representing the 

tag of form. 
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II. 



Built-in Procedures 



A. General usage: 
do {"filename"} 
activate {name} 
decode {form} 

display {form} -- 

displayn {f orm} -- 

define{dir," name",def} -- 
trace {} — 

exit {] 

newob j {} 
newrel {} 

purge {relati on_name} 

B. UNIX system hooks: 

vi {"file"} -- 

system {" command"} — 

shell {} 



Executes rules from file. 

Activate rule denotation. 

Post order dump of nodes. 

Pretty printer. 

Pretty printer. Ends 
with a newline. 

Make a directory entry. 

Toggle the trace function. 

End session. 

Same as Cntl-D. 

Generate a new object. 

Generate a new relation. 

Empty a relation. 

Invoke the VI text editor. 

Pass a command to the 
UNIX shell. 

Spawn a temporary 
UNIX shell. 
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appendix c 

UTILITY FONCTIOSS AND SOLES 



! Function library 

!!!!!!!i!!!!!!2!!!!!!!!2!I!!!!!!i!!lI!!!!!!!J! 

! A dummy forward declaration is used for reverseAux 

2 due to single pass static scoping. 

fn re verseAux[ X ] : Nil. 

fn reverse^ 1] : reverseAux[ 1 , Nil]. 

fn reverseAux[ 11 , 12] ; 

if 11 = Nil -> 12 
else 

reverseAux[ r est[l 1 ] , cons[ first[ 11 ], 12]]. 

fn map[f, 1] : 

if 1 = Nil -> 1 
else 

cons£f[ first[ 1 ] j, map[f, rest[l]]]. 

fn member[x, 1] : 

if 1 = Nil -> Nil 

else if X = f irst[ 1 ] -> 1 

else member[x, rest[l]]. 

fn assoc[x, 1] ; 

if 1 = Nil -> Nil 

else if -• IsList[ f irst£ 1 ] ] j first[l] = Nil 
-> assoc[x, rest[l]] 
else if X = f irst£ f irst£l ] ] -> first[l] 
else assoc[ X/ rest[l]]- 

fn pairlist£ll, 12] : 
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if 11 = Nil I 12 = Nil -> Nil 
else cons[ [ f irst[ 11 ], first[12]]/ 

pa irlist[ r es t£l 1 ] , rest[12]]]. 

fn append[11, 12] ; 

if 11 = Nil -> 12 
else if 12 = Nil -> 11 

else cons[ f irst[ 11 ], append[ rest[ 1 1 ], 12]]. 

fn iota[n1, n2 ] : 

if n1 > n2 -> Nil 

else cons[n1/ iota[n1+1, n2]]. 

fn length[l] : 

if l=Nil -> 0 

else 1 + length[ rest[ 1 ] ]. 

fn ith[ 1, i ] : 

if i<=1 -> 1 

else if l=Nil -> Nil 

else ith[rest£l], i-1]. 



♦♦♦♦**♦♦**♦*♦*♦*»:}!****♦*** * ♦*♦*♦*****♦* 

utilities — ! 
This file contains a set of utility 1 
rules that are automatically loaded ! 
at system boot. ! 



I System Help function 

I 

define {root, "help**, newrelQ}. 
define{root, "HelpLib", newrel {}} . 

Helplib ("?'• , "/work/mcar thur /comm on/summary, help ") 
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Helplib ("relations" , "/work/mcarthur /common/relation. help") . 
HelpLii) ("functions" , "/work/mcarthur /common/function, help" ) . 
HelpLib ("procedure" , "/work/mcar thur /comm on/proce dure .help") . 
HelpLib ("bugs" , "/work/mcarthur/common/bugs. help") . 

Helplib ("sample", "/work/mcar thur/common/sample. help 

/work/mcarth ur/common/*. rul ") . 

Helplib ( "features" , "/work/mcar thur/common/features. help") . 



define [root, "HelpRules", 

« 

! this rule may be invoked by an assertion or a call 

I so both cases are covered. 

if *help(a:l), (-.IsRel[a] 1 length' 1]= 1) -> 

displayn {"Usage : help [""topic""} "} , 
help ["?"} 

else if *help(a, x) , Helplib (x, y) -> 
system ("more " + y) , 
a ("OK") 

else if *help(a, x) -> 

displayn ["Topic not found."}, 
help (a, "?") ; 

» }• 

! Activate the rules 
activate [ HelpRules }. 

displayn [ "For help, enter help {""?""}. " }; 
displayn [} . 



bug rules add to the bug documentation 



define [root, "BugRules", 
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« 

if *Bugs (a) -> 

displayn {"Describe the buy. End with Cntrl-D : , 
system {"mail -s 'Bug Report' mcarthur"} , 
a{" OK") 

»} . 

define{root, "Bugs", newrel{}}. 
activate {BugRules} . 

displayn {"To report a bug, enter Bugs {}."}. 



CopyRel — Copy from one relation to another 
Usage is CopyRel {Rl, R2}. 



define {root, "CopyRel", newrel {}} . 

define {root, "CopyRelRules", 

« 

if CopyRel (a, rl, r2), r1{x:y), -«r2{x:y) -> 
r2 (x: y) 

else if *CopyRel(a, rl, r2) -> 
a ("OK") ; 

»}. 

activate {CopyRelRules} , 

! PP ~ A pretty printer fcr objects. 

1 

! These rules are required because the standard pretty 

1 printer - display - doesn't do lookups on objects. 

I 

! define the relations.... 
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define {root, "Pp", newrel{}}. 
define {root, "PpAux", newrel{}}. 
define {root, "PpRel", newrel{}}. 
define {root, "PpObj", newrel{}}. 
define {root, "DumpDisplay", newrel{}}. 



the rules , . . 

define {root, "PpRules", 



! single member is a gocf by the user 
if *Pp (a :L) , -iIsRel[a] -> 

displayn {"Osage : Pp{x1, x2, 

if *Pp (a :Nil ) -> 
a ("OK") 

else if *Pp(a:[x:L]) -> 

PpAux {x} , 

Pp (a:l) ; 

! Is it a relation ? 
if *PpAux(a, x) , IsRel£x] -> 

PpRel {X, newrelQ}, 
a (" ") 

! or other type of object ? 
else if *PpAux(a, x) , IsObj[x] -> 
PpObj (a, X, objval[x]), 
a("") 

! otherwise just display it 
else if *PpAux(a, x) -> 
displayn {x} , 
a("") ; 

if ♦PpRel(a, x, temp) -> 
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CopyEel £x, temp}, 

DumpDisplay (a, x, temp) ; 

if *DumpDisplay (a, name, E) , *R(x:y) -> 
display {name} , 
display {" ('•} , 
display £x :y} , 
displayn {") . ”} , 

DumpDisplay (a, name, R) 

else if ^DumpDisplay (a, name, R) -> 
a(»") ; 

! Pretty print objects ... 

! Functions require a bit of set up 

if *PpOb j (a, name, def) , Tag{ def ]="FN” -> 
display {"fn "} , 
display {name} , 
displayn {def} , 
a("") 

! otherwise, just display def (might be Nil) 

else if *PpObj (a, name, def) -> 
displayn {def} ; 



» }. 

activate {PpEules} . 



! assert list procedures 

I allows one to assert multiple tuples to a relation 

! Usage is Assert {relname, [tuple], [tuple], ...} 

define{root, " AssertList” , newrel{}}. 
define{root, "Assert Aux", newrel{}}. 
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newrel {} } . 



define {root , "AssertTuple", 

define {root, " Assert List Rules" , 

« 



if *AssertList (a :{ r: L]) , IsRel{ a], IsRel{ r ] -> 

AssertAux(a, r, L) 

else if *AssertList {a;l) -> 

displayn {"Usage : Assert {Relname, ListOf Tuples} , 
a (Nil) ; 

if *AssertAux (a , r. Nil) -> 
a ("OK") 

else if ^Assert Aux (a , r, [x:l]) -> 

AssertTuple {r, x} , 

AssertAux(a, r, 1); 

if *AssertTuple (a, r, x) , -•IsList{x3 -> 

displayn {"Error in Assert -- tuple not a list", x} 

else if *AssertTuple (a, r. Nil) -> 
a (Nil) 

else if *AssertTuple (a, r, [x:!]) -> 
r (x:l) , 
a(r) ; 

»}. 

activate {AssertlistEules} . 
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C0MPAEATI7E APPLICATIONS: OMEGA, LISP, AND PROLOG 



* * 
* Pattern Matching Tests * 

* 



:?c:}c:}c:jc :jc :#c :jc :jc :^c :^c :jc :{c:}c:jc:jc:jc4c:{c:{c:flc:jc:jc4c:Jc:jc:^c:^::^c:^c:{t:jc4c:}c:}c:{c:^c:jc:}c:jc:jc:Jc4c:jc4c:}c:jc:jc:jc 



pattern matching benchmark -- Omega 



define {root, "El”, newrel[}}. 
define{root, "R2", newrelQ}. 
define{root, "genDat”, newrel{)}. 
define{root, "mTest”, newrel{}}. 

define{root, "MatchRules”, 

« 

I the data generating rules 

if *genDat(a, n1, n2), n1 > n2 -> 
a ("OK") 

else if *genDat (a, n1, n2) -> { 

El (n1) ; 

R2(n1 + n2) ; 
genDat (a, n1+1, n2) ; 

} ; 

if *mTest(a) -> { 

El (9999) ; R2 (9999) ; 
genDat {1 , 1000} ; 
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system {” date*’} ; 
if R1 (X) , R2 (X) -> { 

syst em ("date") ; 
displayn {x} ; 

}; 

a ("OK") ; 

} 

»} • 

! activate the rules 
activate {MatchRules} . 



/* 

PROLOG pattern matching benchmark 


r1 (9999) . 
r2 (9999) . 

genDat(Lo, Hi) 

Lo < Hi, 

12 is Lo + Hi, 
asserta (r 1 (Lo) ) , 
asserta (r2 (12) ) , 

Lonext is Lo + 1, 
genDat (Lonex t. Hi). 
genDat (Hi, Hi) . 

mTest (X) 

genDat (1 , 1000) , 
system ("date") , 
r1 (X) , r2(X) , 
system (" date") . 



pattern matching benchmark — Franz LISP 
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(defun genDat (n1 n2) 

(prog (i1) 

(setg i1 n1) 

LOOP 

(cond ((greaterp i1 n2) 

(return) ) 

(t (setg r1 (cons i1 rl)) 

(setg r2 (cons (plus i1 n2) r2)) 
(setg i1 (addi i1) ) 

(go LOOP))))) 

(defun match () 

(prog (t1 t2) 

(setg t1 rl) 

L00P1 

(setg t2 r2) 

L00P2 

(cond ((null t2) 

(cond ((null t1) (return nil)) 

(t (setg t1 (cdr t1)) 

(go LC0P1)))) 

((egual (car t1) (car t2)) 

(return (car 1 1) ) ) 

(t (setg t2 (cdr t2) ) 

(go L00P2)) ) )) 

(defun mlest () 

(setg rl (list 9999)) 

(setg r2 (list 9999)) 

(genDat 1 1000) 

(exec date) 

(match) 

(exec date) ) 
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* 

* Factorial * 

* 

* ^ 



:{c:4c:$t:4^:4E:4c:4c:4c:4f:4e:4c^:^:fc :>$c:4c3$c:^:$c:{c :^c:4c:4e:9(:^:4c:4c:;^:fc:4^^ 



factorial benchmark — Cmega 



fn fact[n] : 

if n <= 0 -> 1 
else n * fact[n-1], 

! driver rules 

define{root/ "Driver”/ newrel{}}. 
define {root/ "factTest"/ newrel{}}. 
define {root/ "DriverEules"/ 

« if *Driver(a/ n) -> { 

if n <= 0 -> a ("OK") 
else -> { 

f act[ 15]; 

Driver (3/ n- 1) 

} 

}; 

! the CSH date function provides a timer 
I times given to the nearest second 

if *factTest (3/ n) -> { 

display {"Omega factorial; ; 
display {n} ; 
displayn {" calls"} ; 
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syst em ("date") ; 
Driver £n) ; 
system ("date") ; 
} ; 



»} • 

! activate the rules 
activate {DriverE ules} . 



/* 

factorial benchmark — Prolog 



fact(N, 1) H =< 0. 
fact (N, F) 

N >= 0, fact(N-1, M) , F is M 

driver (0) . 
driver (N) 

N > 0, fact (15, X), M is N- 1 , 

factTest (N) 

system ("date ") , 
driver (N) , 
system ("date") . 



; Factorial benchmark — Franz LISP 



(defun fact (n) 

(cond ( (lessp n 0) 1) 

( (zerop n) 1) 

(t (* n (fact (- n 1)))))) 






* N. 



driver (M) . 
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; th€ benchmark driver -- 
; (fact 15) executed n times 
(defun driver (n) 

(cond ((e^ual n 0) "OK") 

(t (fact 15) 

(driver (- n 1)) )) ) 

; the CSH date function provides a crude 
; timer to the nearest second. 

(defun factTest (n) 

(exec date) 

(driver n) 

(exec date)) 



:4c:^c*:^c3{c:4c:4c*:4c:^c:<e:4c:4c3ic:4c:4c :^c:<c5{c 



* ^ 

* Prime Number Sieve * 

* * 



+ *2ic 3jc:4:3}c:4c:4c:4c:^c :<c ^ :^c 3}: j}c sjc :^c :4c :^c :4c 34oJc3}c3ic3}c5!c3}c:4e3jc3jc3ic3jc:4c3ic3{c3ic3ic*:4c 



sieve benchmark -- Omega 



define {root, "Primes", newrel£}). 
define{root, "PrimesAux", newrel{}}. 
define {root, "sTest", newrel {} } - 

fn PurgeMults[ X, 1] : 

if 1 = Nil -> Nil 

else if first[l] % x = 0 -> 

PurgeHults[ X, rest[l]] 
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else [ first[ 1 ]: Purgeilul ts£ X, rest[l]]]. 

define {root , '•SieveRules", 

« 

if *Primes(a, n) -> 

PrimesAux (a# iota[2# n]. Nil); 

if ^PrimesAux (a , Nil# 1) -> 
a (reverse£ 1 ]) 

else if *PrimesAux (a#£x:11 ]/ 12) -> 

PrimesAux (a , PurgeMults£x, 11]# [x;12]); 

if *sTest(a) -> £ 

system {"date*'} ; 

Primes {350} ; 
system {"date"} ; 
a ("OK") ; 

} ; 

»} . 

activat e {SieveSules} . 



/* 

Sieve benchmark — Prolog 



primes (Limit, Ps) 

iota (2, Limit, Is), 
sift (Is, Ps) . 

iota(Io, Hi, [Lo|Eest]) 

Lo =< Hi, M is Lo+1, iota(M, Hi, Rest), 
iota (_, _, £ ]) . 

sift (£ :, £ ]) . 

sift (£HIs], £IlPs]) 

remove (I, Is, New), sift (New, Ps) . 



*/ 



177 



remov€(P, [ ], [ ]) . 
remove(P, [Ills], [IlNis]) 
not (0 is I mod P) , 
remove (P, Is, Nis) . 
remove(P, [Ills], Nis) 

0 is I mod P, remove(P, Is, Nis). 



sTest 

system (" date") , 
primes (350, Ps) , 
system (" date") , 
print (Ps) . 



sieve benchmark — Franz LISP 



(defun iota (nl n2) 

(cond ((greaterp nl n2) nil) 

(t (cons nl (iota (addi nl) n2))))) 

(defun purgeMults (x 1) 

(cond ((null 1) nil) 

((zerop (mod (car 1) x) ) (purgeMults x (cdr 1) ) ) 
(t (cons (car 1) (purgeMults x (cdr 1)))))) 

(defun primes (n) 

(primesAux (iota 2 n))) 

(defun primesAux (1) 

(cond ((null 1) nil) 

(t (cons (car 1) 

(primesAux 

(purgeMults 
(car 1) 

(cdr 1))))))) 
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(defun sTest () 
(exec date) 
(primes 350) 
(exec date)) 



:jc 5fc :#c :<c :^c :{c :}c :{c :<c :{c :jc * 



:«c * 

* Quicksort * 

* 

:«c :^c 



:^c:^c:4c:Jt:fc:#t:^c:ic:jc:<c:jt4c:^c:{c :#c :flc :{c :^c :^c :}c :^c :$c :jc :^c :^c :{c 



Quicksort benchmark — Cmega 



fn iotaR[n1, n2] : 

if n1 > n2 -> Nil 

else [ n2 : iotaR[ n1 , n2-1*]. 

define {root, "Qsort”, newrelQ}. 
define{root, "QsortAux'*, newrelQ}. 
define {root, "gTest”, newrel {} } . 

define {root, "QsortRules", 

« 

! Quick Sort 

if *Qsort(a, Nil) -> 
a (Nil) ; 

if *Qsort(a, [x:L]) -> 

QsortAux (a, x, L, Nil, Nil) ; 
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if *QsortAux(a, x. Nil, 11, 12) -> 

a (append[ Qsort {11 } , [ x ; Csort {12} j ]) ; 
if *QsortAux(a, x, [y:11], 12, 13) -> { 
if y <= X -> 

QsortAux (a, x, 11, {y;l2], 13) 

else 

QsortAux(a, x, 11, 12, [ y : 13 ]) 

} ; 



if *glest(a, n) -> { 

system {" date"} ; 
Qsort {iotaE[ 1 , n ]} ; 
system {"date”} ; 
a ("OK") ; 

}; 

»} . 



activate {QsortRules} . 



/* Quicksort Benchmark 



Prolog 



*/ 



gsort ([ H I T],S) : - 

split (H,T,A,B) , 
gsort (A ,A1) , 
gsort (B ,B1 ) , 
append (A 1,[ H |B1 },S) . 
gsort (i; ], [ ]) . 

split (H,[A| X],[A|Y],Z) 

A < H, 

split (H,X,Y,Z). 
split (H,[AIX],Y,[A1Z]) 

H < A, 

split (H,X,Y,Z). 
split {_,[ ],[ ],[ ]) . 
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append (£ ],L,L) . 
append([HlT],L,[HlV j) 
append (T,L, V) . 

iotaE (Lo, Hi, [HilRest]) 

lo =< Hi, M is Hi-1, iotaR(Lo, M, Rest) . 
iotaR (_, _, [ ]) . 



gTest (N) 

system ("date'*) , 
iotaR (1, N, L), 
gsort (L , S) , 
system ("date") , 
print (S) . 



; Quicksort Benchmark — Franz LISP 



(defun gsort(l) 

(cond ((null 1) nil) 

(t (setg s (split (car 1) (cdr 1))) 

(append (gsort (car s) ) 

(cons (car 1) (gsort (cadr s) )))))) 

(defun split (x 1) 

(prog (s) 

(cond ((null 1) (return (list nil nil)))) 

(setg s (split x (cdr 1))) 

(cond ( (lessp (car 1) x) 

(return (list (cons (car 1) (car s) ) (cadr s) ) ) ) 
(t 

(return (list (car s) 
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(cons (car 1) (cadr s) )))))) ) 



(defun iotaR (n1 n2) 

(cond ((greaterp nl n2) nil) 

(t (cons n2 (iotaR nl (subi n2) ) ) ) ) ) 

(defun gTest (n) 

(exec date) 

(gsort (iotaR 1 n) ) 

(exec date)) 



♦ * 

* Missionaries and Cannibals: * 

* A State Search Problem * 

* * 



Missionaries and Cannibals -- Omega 
Generate and test search strategy 



define {root, "me", newrelQ}. 
define{root, '’misCan*', newrel{}}- 
define{root, "PpL”, newrelQ}. 

define { root, ’’misCanRules” , > 

« 

if *mc(nM, nC) -> 

misCan ( 1 , nM , nC , nM, nC, 0, 0 , Nil) ; 
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if misCan{s,nM,nC,0/0,nil,nC/path) 

-> { 

purge {misCan} ; 

PpL {£[s,0,0, nM, nC J; path ]} ; 
displayn {''Finis "} 

} 

else if *mi scan {S/ nM, nC, ml , cL, mR# cE /path) , 

{ml >= 0 & ml <= nM S 

cL >= 0 S cL <= nC 5 

mR >= 0 S mR <= nM & 

cR 0 & cR^“ nC& 

(ml >= cL I ml = 0) & 

(mR >= cR I mR = 0) ) , 

-imemter[ [ s, mL,cI,mR,cR],path] 

-> 

misCan ( (0-s) , nM, nC, mL-S/ cL / mR + s, cR , 
s, mL,cL, mR, cR ;path ),] 
misCan { (0-s) ,nM, nC, mL ,cL-s, mR, cR+s , 

£, mL, cL, mR, cR : pa th ) ,] 
misCan { (0-s) ,nM,nC,mL,cL-2*s, mR,cE+2*s, 
s, mL, cL, mR, cR :path ),] 
misCan { (0-s) , nM, nC, mL-2*s, s L,mE + 2*s, cR , 
s, mL, cL, mR, cR :path ),] 
misCan ( (0-s) ,nM,nC, mL -s, cL-s, mE + s, cR+s , 
s, mL, cL, mR, cE :path ) ] 

else if *misCan (s,nM ,nC ,mL, cL, mR, cE, path) ->; 

! a small pretty printer for the output list 

if *PpL(a, Nil) -> 

else if *PpL (a, [x:L]) -> { 

PpL {L} ; 
displayn {x} ; 

} 

» }. 
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activate { misCanRules }. 



/* 

Missionaries and Cannibals -- Prolog 




mc(Nm,Nc) misCa n { -1 , Nm, Nc / 0 , 0, Nm , Nc, [ ]) . 

misCan (S,Nm,Nc,Nm,Nc, 0,0, Path) 

Nm >= Nc, ppL ([[ S,Nm,Nc ,0,0 ]1 Path ]) . 

misCan (S,Nm,Nc,Ml,Cl,Mr,Cr, Path) 
safe(Nm,Nc,Ml,Cl,Mr,Cr) , 
equal ([ S , Ml, Cl, Mr,Cr ],P), 
not (member (P ,Path) ) , 

SI is -S, 

possible (S,Ml,Cl,Mr ,Cr, Ml 1 , Cl 1 ,Mr 1 , Cr 1) , 
misCan {S1,Nm,Nc,M11,C11,Mr1,Cr1,[P| Path ]) . 

safe (Nm,Nc,Ml,Cl,Mr,Cr) 

Ml >= 0, Ml =< Nm, 

Cl >= 0, Cl =< Nc, 

(Ml >= Cl ; Ml =:= 0) , 

(Mr >= Cr ; Mr =:= 0). 

possible (S,Hl,Cl,Mr,Cr,Ml1,C11,Mr1,Cr1) 



(Mil 


is 


M1-2+S, 


Mr 1 


is 


Mr + 2*S, 


C11 


is 


Cl, 


Cr 1 


is 


Cr) ; 


(Mil 


is 


Ml, 


Mrl 


is 


Mr, 


C11 


is 


Cl-2*S, 


Cri 


is 


Cr+2*S) ; 
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(Mil 


is 


Ml-S , 


Mr 1 


is 


Mr+S, 


Cll 


is 


Cl-S , 


Cri 


is 


Cr+S) ; 


(Mil 


is 


Ml-S, 


Mr1 


is 


Mr+S , 


Cll 


is 


Cl, 


Cri 


is 


Cr) ; 


(Mil 


is 


Ml, 


Mr 1 


is 


Mr, 


Cll 


is 


Cl-S , 


Cri 


is 


Cr+S) . 


.[ ]) 


• ^ 


! , f ail 



member (X,[ X 1 L]) . 

member (X,[ Y 1 L ]) member (X,L) 



equal (X, X) . 

PPL {[ ]) • 

ppL(i;xjL]) print (X), nl, ppL (L) . 
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appendix e 

OHEGA APPLICATION EXAMPLES 






Monte Carlo Simulation for 3 node message network. 



^ :jc :}c ;}£ :}£ :}c :4c ^ :jc :}c :}c 3{s jf: :}c jjc jJc :jc 3 }: * :^t 3 }: :{t :^c :)c * :}c :{c :}c :jc 3>4c=>:3}c:}c3ic:J:4c=>:5}c4:j!ca{£:Jc:fr:4c3}c*:fc :jc :4c:}c 3ic4c 



the relations 



define (root , 
define {root, 
define {root, 
define {root, 
define {root, 
define {root, 
define {root , 
define {root, 
define {root , 
define {root , 
define {root, 
define {root , 
define {root, 
define {root, 
define {root, 
define {root, 
define {root, 
define {root, 
define {root, 
define {root, 
define {root, 
define {root, 
define {root. 



"Begia", newrel {} } . 

"End", newrel {} 3 . 

"Clock", newrel {3 } . 

" NextTime" , newrel {3 3- 
"LastTime", newrel Q}* 

"Event", newrel {3 3 . 
"ProcessEvents " , newrel {3 3- 
"ProcessEventsA ux" , newrel {3 3 • 
"Summary", newrel {33 . 

"Status", newrel 13 3 . 
"BusyTime", newrel 0 } • 
"QLength", newrel {33 • 

"Stats", newrel {3 3 . 
"BusyStats", newrel{33- 

"QStats", newrel {3 3* 

"Totals", newrel {3 3* 
"NodeTotals", newrel {3 3* 
"JobTotals", newrel{33. 

" JobTotalsAux" , newrel {3 3- 
"Displayline", newrel {3 3 . 
"Start", newrel {3 3- 
"Arrive", newrel{33- 
" Ne wArrival" , newrel {3 3* 
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define {root, 
define {root , 
define {root, 
define {root, 
define {root, 
define {root, 
define {root, 
define {root, 
define {root, 
define {root, 
define {root , 
define {root, 
define {root, 
define{root, 
define {root, 
define {root, 
define {root, 
define {root, 
define {root , 
define {root, 
define {root, 
define {root, 
define {root. 



"Service", newrel {}} . 
"StartTime", newrel{}}. 
"Depart", newrel {}}. 
"ExitTime", newrel 0}- 
"InService", newrel{}}. 

"Q" , newrel {} } . 

"Eng", newrel {}} . 
"CalcNextArr ", newrel {}}. 

" CalcDeparture" , newrel {}}. 
"CalcRoute", newrel{}}. 
"NewJol", newrel{}). 

" JobServiceT", newrel {}}. 
"JobCount", newrel 0}* 
"GenArrT", newrel {}} . 
"GenServT", newrel {}} . 
"GenRoute", newrel Q}. 
"ServiceTime", newrel {}}. 

" Arrinterval", newrel {}}. 

" PossibleRoutes ", newrel {}}. 
"Seed", newrel{}}. 

"Rnd", newrel {}}. 

"RndList", newrel {}}. 
"WorkList", newrel 0 ) . 



the Nodes 



define {root, "Nodel", newobj{}}. 
define{root, "Node2", newobj{}}. 
define{root, "Node3", newobj{}}. 
define {root, "Out", newobj{}}. 



! initalize MonteCarlo tables 

! Service times (message transmission times) 

ServiceTime (1 , 0, 12). 
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ServiceTime (2, 13, 


32) 


• 




ServiceTime (3, 33, 


7 9) 


• 




ServiceTime (4 , 80, 


9 2) 


• 




ServiceTime (5, 93, 


99) 


• 




! Interarriva 


l1 times 


Arrinterval (Nodel, 


1/ 


0, 


16). 


Arrinterval (Nodel, 


2, 


17, 


24) . 


Arrinterval (Nodel, 


3, 


25, 


49) . 


Arrinterval (Node 1 , 


4, 


50, 


9 1) . 


Arrinterval (Node 1, 


5, 


92, 


99) . 


Arrinterval (Node2, 


1/ 


0, 


28) . 


Arrinterval (Node2, 


2, 


29, 


70). 


Arrinterval (Node2, 


3, 


71, 


85). 


Arrinterval (Node2, 


4, 


86, 


92) . 


Arrinterval (Node2, 


5, 


93, 


99) . 



Routing table 



PossibleRoutes^(Node 1 , 


Node2, 


0, 


29) 


PossibleRoutes (Nodel , 


Node3, 


30, 


59) 


PossibleEoutes (Nodel , 


Out, 


60, 


99) 


PossibleRoutes (Node2 , 


Nodel , 


0, 


29) 


PossibleEoutes (Node2, 


Node3 , 


30, 


49) 


PossibleEoutes (Node2 , 


Out, 


50, 


99) 


PossibleRoutes (Node3 , 


Out, 


0, 


99) 


I Random number 


table 







RndList ([ 

97,9 5, 12,1 1,90, 4 9, 57,13,86, 81, 
02,92,75,91,24,58,39,22, 13,02, 
80,6 7, 14,9 9, 16,8 9, 96,63,00,04, 
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96 , 76,2 0 , 28 , 72 , 12,77 , 23 , 79,4 6 , 
55 , 6 4 , 82 , 61 , 73 , 94 , 26 , 18 , 37 , 31 , 

50 . 02 . 74 . 70 . 16 . 85 . 95 . 32 . 85 . 67 , 
29 , 53 , 08 , 33 , 81 , 34 , 30 , 21 , 24 , 25 , 
58 , 16 , 01 , 91 , 70,0 7 , 50 , 13 , 18 , 24 , 
51 , 16 , 69 , 67 , 16 , 53 , 11 , 06 , 36 , 10 , 
04 , 55 , 36 , 97 , 30 , 99 , 80 , 10 , 52 , 40 , 
86 , 54 , 35 , 61 , 59 , 89 , 64 , 97 , 16,0 2 , 
24 , 23 , 52 , 11 , 59 , 1 0 , 88 , 68 , 17 , 39 , 

39 . 36 . 99 . 50 . 74 . 27.6 9 , 48 , 32 , 6 8 , 

60 . 71 . 41 . 25 . 90 . 93 . 07 . 24 . 29 . 59 , 
65 , 88 , 48 , 06 , 68 , 92 , 70 , 97 , 02 , 66 , 
44 , 74,1 1 , 60 , 14 , 57,0 8 , 54 , 12 , 90 , 
93 , 1 0 , 9 5 ; 80 , 32 , 50 , 40 , 44 , 08 , 12 , 

20 . 46 . 36 . 19.4 7 , 78 , 16 , 90 , 59 , 64 , 
86 , 54 , 24 , 88 , 94 , 14 , 58 , 49 , 80,7 9 , 
12 , 88 , 12 , 25 , 19 , 70 , 40 , 06 , 40 , 31 , 
42 , 00 , 50 , 24 , 60 , 90 , 69 , 60 , 07 , 86 , 

29 . 98 . 81 . 68 . 61 . 24 . 90 . 92 . 32 . 68 , 

36 . 63 . 02 . 37 . 89 , 4 0 , 81 , 77 , 74 , 82 , 

01 . 77 . 82 . 78 . 20 . 72 . 35 . 38 . 56 . 89 , 

41.6 9 , 43 , 37 , 41 , 21,36 , 39 , 57 , 8 0 , 

54.4 0 , 76 , 04 , 05 , 01,45 , 84 , 55 , 1 1 , 
68,0 3,8 2,3 2 , 22 , 8 0 , 92 , 47 , 77,6 2 , 
21 , 31 , 77 , 75 , 43 , 13 , 83 , 43 , 70 , 16 , 

53.6 4 , 54 , 21 , 04 , 23 , 8 5 , 44 , 81 , 36 , 

91 . 66 . 21 . 47 . 95 . 69 . 58 . 91 . 47 . 59 , 
48 , 72 , 74 , 40 , 97 , 92 , 05 , 01 , 6 1 , 1 8 , 
36 , 21 , 47 , 71 , 84 , 46 , 09 , 85 , 32 , 82 , 
55,9 5 , 24,8 5 , 84,5 1 , 61 , 60 , 62 , 13 , 
70 , 27 , 01 , 88 , 84 , 85,77 , 94 , 67 , 35 , 
38 , 13 , 66 , 15 , 38 , 54 , 43 , 64 , 25 , 43 , 
36 , 80 , 25 , 24 , 92 , 98 , 35 , 12 , 17 , 62 , 
98 , 10 , 91 , 61 , 04 , 90 , 05 , 22 , 75,2 0 , 
50 , 54 , 29 , 1 9 , 26 , 26 , 87 , 94 , 27,73 
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]) • 



WorkList (Nil) . 

! Intialize Queues 

Q(Node1, Nil). 

Q(Node2, Nil). 

Q (Nodes, Nil). 



! the Precedence function 

! Scheme is (for events Stime=t, node=n) 

! Departures have top priority 

! Between occurrences of same type of event 

! JobN 1 precedes JobN2 if N 1 < N2. 

! This function replaces a sort on the event list. 

fn ?recedence[ e 1 , j1, e2, j2] : 

if e1=e2 & j1<j2 -> "TRUE" 

else if e1 = Depart 5 e2 -<= Depart -> "TRUE" 
else Nil. 

! The Rules 

define (root, "SimRules", 

« 



Begin — Begins the simulation and sets up relations 



if *Begin(a, n) -> { 

JobCount (0 , 0, n) ; 
LastTime (0) ; 
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InService (No del 


II fl\ . 

t ; t 


InService (Node2 


II ii\ . 

/ y # 


InService (NodeS 


II ii\ . 

t J t 


BusyTime (Nodel, 


0 ) ; 


BusyTime (Node2, 


0) ; 


BusyTime (NodeS, 


0) ; 


QLength (Nodel, 


0) ; 


QLength (Node2, 


0) ; 


QLength (Node3, 


0) ; 


Event (0, Start, 


II 11 II 

t 


Clock (0) ; 




a ("OK”) ; 




}; 





J End — Cleanup for further runs 

I 

if *End (a) -> £ 

purge £JobCount) ; 
purge {InService} ; 
a (End) ; 

) ; 



! the clock rules — drives the simulation 

I 

if *Clock(999), *LastO:ime(t) -> £ 

Totals £t} ; 

End £} ; 

} 



else if *Clock(t2), *LastTime (t 1) -> £ 

19 1 



Stats£t1 , t2} ; 
displayn { 

.. . 

display £ "Time : 
displayn £t2} ; 
displayn £"Ev ents ; 

ProcessEvents £t2} ; 

Summary £} ; 

LastTime (12) ; 

Clock ( NextTime £999} ) ; 1 restart the clock 

}; 

if *NextTime{a, t1) , Event(t2, €, n, j) , t2 < tl -> 
NextTime (a, t2) 

else if *NextTime(a, t) -> 
a (t) ; 



I 

1 



Process all events for time t 



if *ProcessEvents (a , t) , Event (t, el, nl, j1) -> £ 

ProcessEventsAux £t , el, n1, j1}; 

ProcessEvents (a, t) ; 

} 

else if *ProcessEven ts (a, t) -> 
a(t) ; 

if *ProcessEventsAux (a, t, el, n1, jl). 

Event (t, e2, n2, j2) , 

Pr ecedence[ e2 , j2 , el, j1 ] -> 

ProcessEvent sAux (a, t, e2, n2, j2) 

else if *ProcessEventsAux (a, t, e, node, job) -> £ 

-■Event (t, e, node, job) ; 

€ £t , node, job] ; 
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display {" ; 

displayn {e, node, job); 
a(t) ; 

}; 



Summarize the current status for all nodes 



if *Summary (a) -> { 

Status {Node 1} , Status {Ncde2} , 
displayn {] ; 

displayn {"Pending Events 
Pp {Event} ; 
displayn {} ; 
a(”") ; 

}; 



Status {Node!} ; 



if *Status(a, node), InService ( rode, job), Q(node, 1) -> 

£ 

displayn {node} ; 

display{" Job in service : "} ; 

displayn {job} ; 

display {" Jobs in queue : "} ; 

if l=Nil -> displayn {»»--"} 
else displayn {!}; 
a (node) ; 

} ; 



Keep running totals for stats on each node. 

The relations are : 

BusyTime (node, t) -- Cumulative idle time 
QLength (node , n) -- Time weighted Q length 
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I 



if *Stats(a, t1, t2) -> { 

BusyStats {t 1 , 12, Node1}; 
BusyStat s {t 1 , 12, Node2}; 
BusySlals {1 1 , 12, Node3}; 
QSlals£11, 12, Nodel) ; 
QSlals£11, 12, Node2} ; 
QSlals£11, 12, Node3) ; 
a(11) ; 

) ; 



if *BusySlals (a, 11, 12, node), InService (node, -> 

a (node) 

else if *BusySl als (a , 11, 12, node), *BusyTime (node , 1) -> 
BusyTime (node, 1+12-11) , 
a (node) ; 

if *QSlals(a, 11, 12, node), *QIenglh (node,n) , Q (node,l) -> 
QLenglh (node , n + (12-1 1) *lenglh[ 1 ]) , 
a (node) ; 



lolals — Display slal summary al end of simulalion 



if *Tolals(a, 1) -> £ 

display £” Tolal lime : ; 

displayn £1} ; 
displayn £} ; 

DisplayLine £[ ’’Node”, "Busy”, "QLen"]}; 

DisplayLine £[ " " ]} ; 

NodeTolals £Node1} ; 

NodeTolals £N cde2} ; 
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NodeTotals {Node3} ; 
displayn {) ; 

DisplayLine {[ "Job”, "Time"]} ; 

DisplayLine [[" " ]} ; 

JobTotals{Nil, 0} ; 
a (t) ; 

} ; 

if *NodeTotals (a , node), *BusyTime (node, t) , 
♦QLength (node , n) -> ( 

DisplayLine {' node, t, n ; 
a (node) ; 

}; 

if *JobTotals (a, 1, n) , 

♦ StartTime ( j , tl), *ExitTime (j, t2) -> 

JobTotals(a, cons[[j, t2-tl ], 1], n+t2-tl) 

else if *JobTotals (a , 1, n) -> ( 

JobTotalsAux {1} ; 
displayn {} ; 

DisplayLine {[ "Total" , n ]} ; 
a (JobTo tals) ; 

} ; 

if *JotTotalsAux (a. Nil) -> 
a (JobTotalsAux) 

else if *JobTo talsAux (a, 1) -> { 

DisplayLine £f irst[ 1 ]] ; 

JobTotalsAux (a, rest[ 1 ]) ; 

} ; 



if ^DisplayLine (a. Nil) -> { 
displayn {} ; 
a (DisplayLine) ; 
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} 

else if ^DisplayLine (a, 1) -> { 
display {" ") ; 

display {first[l ]} ; 

DisplayLine (a, rest[l]) ; 

} ; 

I 

! the events -- Start, Arrive, Depart 

t 

if *Start(a, t, x, y) -> { 

CalcNext Arr £t, Nodel}; 

CalcNext Arr { t, Node2} ; 
a(t) ; 

} ; 

if *Arrive(a, t, node, ''HewJob") -> { 

NewArrival (t , node, NewJob[}}; 
a(t) 

} 

else if ^Arrive (a, t. Out, job) -> { 

ExitTime ( job , t) ; 
a(t) 

} 

else if ^Arrive (a, t, node, job) -> £ 

Service £t, node, job}; 
a (t) ; 

} ; 

if *New Arrival (a, t, node, job) -> £ 
StartTime ( job, t) ; 

CalcNextArr £t , node); 

JobServiceT ( job, GenSer vT £Rnd £} } ) ; 
Service £t, node, job}; 



196 



a(t) ; 

} ; 



if *Service{a, t, node, job), *InService (node, -> { 

InService { node, job); 

CalcDepart ur e {t, node, job}; 
a(t) 

} 

else if ^Service {a, t, node, jot) -> { 

Eng {node, job}; 
a(t) ; 

}; 

if ^J'DepartCa, t, node, job), 

Q{node, Nil), *InService {node, job) -> 

InService (node, " — "), 
a(t) 

else if ^Depart (a, t, node, job), 

*Q(node, 1), *InService (node, job) -> 

{ 

Q(node, rest[l]) ; 

InService (node, " — ") ; 

Service {t, node, first[l]}; 
a (t) ; 

} ; 



if *CalcNextArr (a, t , ncde) , JobCcunt (n1, n2, max) , n1> = max -> 
a(t) 

else if *CalcNextArr (a, t, node) , *JobCount (n1 ,n2, max) -> 

{ 

JobCount (n1+ 1, n2, max) ; 

Event (t + GenArrT {node, End {} } , Arrive, node, "New Job") ; 
a(t) ; 
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} ; 



if *CalcDeparture (a, t,node, job) , JobServiceT (job ,servT) -> 

C 

Event (t+ser vT, Depart , node, job) ; 

Event (t+servT, Arrive ,GenEou t e [node. End [} } , job) ; 
a (t) ; 

} ; 



if *Eng(a, node, job), *Q(node, 1) -> 

Q (node, append[l, 
a (node) ; 

if *NewJob(a), * JobCount (n1 , n2, max) -> 
JobCount(n1, n2+1, max), 
a ("Job" + int_str[n2+ 1 ]) ; 



I parameter generators 

! GenServT — Generate a service time for a message 

! GenArrT -- Generate an interarrival time for a job 

! GenEoute — Generate the next node for a departure 

j 

if *GenServT(a, x) , ServiceTime (t , il, i2) , 

(X >= il) & (X <= i2) -> 

a(t) ; 

if *GenArrT(a, node, x) , Arr Int erval (node, t, il, i2) , 

(X >= il) & (X <= i2) -> 

a(t) ; 
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if *GenEoute{a, node, x) , PossitleRoutes (node, n2, i1, i2) , 



(X >= i1) 5 (X <= i2) -> 

a (n2) ; 



The random number generator .... 

The End procedure takes the first number from the 
list of random numbers in WorkList. 

Seed makes the WorkList the portion of the 
EndList with the ith member as the first member. 
If the list of random numbers is exhausted, 
the WorkList is set back to the beginning of 
the original list of random numbers. 



if *Seed{a, n) , EndList (1), *WorkList (wl) -> 
WorkList (ith[ 1, n ]) , 
a (n) ; 

if *Rnd(a), *WorkLis t (Nil) , Endlist(l) -> 
WorkLis t (rest[ 1 ]) , 
a (f irst[ 1 ]) 

else if *End(a) , *WorkList(l) -> 

WorkLis t (res t[ 1 ]) , 
a (first[ 1 ]) ; 



»}. 

! Activate the rules... 

activate (SimEules) . 
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! Towers of Hanoi ! 

j ; 

f :^c:{c5!c :^^:{c5{c5^::^c5!c5!c:^c:^c:^c:}c 5}c:^c5!c 5 }c:4c :4c:^c:}c:4c5{c5;65{c:^c:jc:^c:^c:4c^^c5!c:{c:^e:^c:^c:^c:^ 

! define the relations 

define [root/ “Hanoi"/ newrel {} } . 
define£root/ "HanoiAux", newrel 0 ) • 

! The rules 

define [root/ "HanoiR ules" / 

« 



if *Hanoi(a/ n) -> 

HanoiAux (a/ U/ "A"/ "C"/ "B") ; 

if *HanoiAux(a/ from, to, aux) -> £ 

display ["Move disk 1 from peg ; 
display [from} ; 
display [" to peg "} ; 
displayn [to] ; 
a ("") 

3 

else if *HanoiAux(a/ u, from/ tC/ aux) -> [ 

HanoiAux [n- 1 / from/ auX/ to}; 
display ["Move disk "} ; 
display £n} ; 

display[" from peg "} ; 
display [from} ; 
display [" to peg "} ; 
displayn [to} ; 

HanoiAux [n- 1 / auX/ to, from}; 
a("") ; 

3 

» 3 - 
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activate {HanoiEules} . 

displayn ("Towers of Hanoi : Usage : Hanoi {n}"}. 






! The Sieve of Eratosthenes 

I 

!For a description of this algorithm, see 
! ' Era tosthenes revisited : Once More through the Sieve’, 
!by Jim and Gary Gilbreath, Byte, Jan 83, p 283. 

I 



define {root, "Sieve", newrel {} } . 
define {root, "SieveAu:x", newrel 0}* 
define{root, "Iota", newrel{}}. 
define{root, "PurgeMultiples ", newrel{}}. 

! the rules 

define {root, "SieveEules" , 

« 

if *Sieve(a, n) -> system ("date") , 

SieveAux(a, 0, n-1, lota{0, n-1, newrel{}}); 

if *Iota(a, n1, n2, r) , n1 > n2 -> 
a(r) 

else if *Iota (a , n1, n2, r) -> 
r (n2) , 

Iota(a, n1, n2-1, r) ; 

if *SieveAux(a, n1, n2, r) , n1 > n2 -> 
a ("OK") , 

else if *SieveAux(a, n1, n2, r) , r(n1) -> { 
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display {"Prime : ; 

displa yn {2*n 1 + 3}; 

PurgeHultiples{2*nl + 3, 3*nl + 3, n2, rj ; 
SieveAux (a, nl+l^ n2, r); 

} 

else if *SieveAux(a, n1^ v.2, r) -> 

SieveAux (a, nl+1, n2, r); 

if *PurgeM ultiples (a , prime, sue, n, r) , sum > n -> 
a (r) 

else if *PurgeMultiples (a, prime, sum, n, r) , *r (sum) -> 
PurgeHultiples (a, prime, prime+sum, n, r) 

else if *PurgeMultiples (a, prime, sum, n, r) -> 

PurgeMultiples(a, prime, prime + sum, n, r) ; 

» }• 

activate {SieveHules} . 

displayn {"The sieve is loaded : Osage ; Sieve {n} . 



I 

Rules and associated definitions for a universal I 
interpreter/pretty printer for a small language of! 
arithmetic expressions. J 

I 



! definitions 

define {root, "Small", newrel {} ) ; 
define{root, "Wait", newrel {]} ; 
define {root, "Eval", newrel {)}; 
define{root, "Value", newrel {}} ; 
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define {root, 
define {root, 
define {root, 
define {root, 
define {root, 
define {root, 
define {root, 
define {root. 



"Appl”, newrel{}}; 
"Op", newrel {} } ; 
"Left", newrel {}}; 
"Right", newrel {}} ; 
"Con", newrel {)}; 
"Litval", newrel {}}; 
"Meaning", newrel {}} ; 
"Template", newrel {}) ; 



! seme 


ob jec' 


ts 




define {root. 


"N1 ", 


newob j 


{}} ; 


define {root. 


"N2", 


newob j 


£3 3 ; 


define {root. 


"N3", 


newob j 


£3 3 ; 


define {root. 


"N4 ", 


newobj 


£3 3 ; 


def ine{root. 


"N5", 


newob j 


£3 3. 



! functions 

fn Id[x] : x; 

fn Sum£x,y] : x + y; 

fn Product£x,y] ; x * y; 

fn upSum£x,y] ; "{" + x + " + " + y + 

fn upProd£x,y] : " (" + x + " x " + y + ")". 



! initialize the database 

Appl (N1) ; 

Cp("x", N1) ; 

Left (N2, N1) ; 

Eight (N3, N1) ; 

Appl (N2) ; 

0p("+", N2) ; 
left(N4, N2) ; 

Right (N5, N2) ; 
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Con (N3) ; 



litval (6 ,N3) ; 

Con (H4) ; 
litval (3, N4) ; 

Con (N5) ; 

Litval(5,N5) ; 

Meaning (Sum, 

Meaning (Product, "x”) ; 
Meaning(Id, "lit"); 

Template (upSum, "+") ; 
Template (upProd, "x") ; 
Template (in t_str, "lit"); 



the Rules 



define {root, "SmallRules", 

« 

! Driver rule 
if *Small(node) 

-> 

Eval (Meaning , 
Eval (Template 
Wait (node) ; 

if *Value (Meaning, x, 

♦ Value (Template, y 

♦ Wait (node) 

-> 

displayn (x) , 
displayn (y) ; 

! Inheritance rules 



node) , 
code) 

node) , 
node) 



! Leaf node 
if 

♦Eval (class , e) , 



Con (e) , 

Litval (v ,e) , 
class (f, "lit") 

-> 

Value{class, x[v], e) 

! Appl node 
if 

*Eval (class , e) , 

Appl (e) , 

left(x,e). Right (y,e) 

-> 

Eval (class, x) , 

Eval (class, y) ; 

! Synthesis rule 

if 

♦Value (class , u,x), 

♦Value (class, v,y), 

Appl (e) , 

Op (n#e) , 

Left (x,e) , 

Eight (y, e) , 
class (f, n) 

-> 

Value(class, f[u,v]. 



» }. 

! activate the rules 

activate { SmallRules }. 

displayn {"Small interpreter loaded : 



e) 



u Small (N1) "} 
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